Disappointment occurs when expectations don’t match reality. And our expectations for software quality are profoundly unrealistic. Thus, lots of people are continuously disappointed — even enraged — by software bugs. They shouldn’t be.

…

This is not a call to give up on software quality, quite the contrary. This is a call to remove the highly charged emotional responses of encountering the world as it should be expected to spin. Demeaning developers, questioning their professionalism (whatever that means!), or feigning outrage at that which ails all software makes everyone, including users, worse off.

So next time you hit an annoying bug, give it five minutes before you fire off that indignant tweet. Marvel at the miracle it is that anything as complex as a modern piece of software works at all! Consider the billions of instructions our work-horse CPUs have to get just right for you to enjoy the splendors of computing. Have some sympathy for man and machine.

If you’re a social entrepreneur building open knowledge resources – open software, open textbooks, open science – you need people to share their knowledge, code and data with you. Your success depends on it.

Contributors to your open project invest their time and energy because they trust you with their gift to the world. So the challenge is this: How can you keep their trust? Can you seal it in for the long term?

There are many successful projects that have managed this, notably in open-source software…

…

How Open Locks work

An Open Lock is a binding commitment in the foundational documents of an enterprise to share knowledge under open licenses. Sometimes it includes a commitment not to close knowledge in a certain way. For example, an Open Lock could state that an enterprise will not apply for software patents.

…

The legal effect of an Open Lock is that no one who acts for a company has the legal authority to lock knowledge down.

And, of course, the agreement templates are available in a GitHub repository.

Less than two years after my presentation titled “Open source for the government”, and almost exactly one year after I became advisor to the deputy prime minister of Bulgaria, with the efforts of my colleagues and the deputy prime minister, the amendments to the Electronic Governance Act were voted in parliament and are now in effect. The amendments require all software written for the government to be open-source and to be developed as such in a public repository.

…

That does not mean that the whole country is moving to Linux and LibreOffice, neither does it mean the government demands Microsoft and Oracle to give the source to their products. Existing solutions are purchased on licensing terms and they remain unaffected (although we strongly encourage the use of open source solutions for that as well).

It means that whatever custom software the government procures will be visible and accessible to everyone. After all, it’s paid by tax-payers money and they should both be able to see it and benefit from it.

We set out to flex our data science muscles, and see if we could come up with an objective standard for what makes a good GitHub README using machine learning. The result is the GitHub README Analyzer demo, an experimental tool to algorithmically improve the quality of your GitHub README’s.

…

Some of our assumptions proved to be true, while some were off. We found that our assumption about headers and the text from paragraphs correlated with popular repositories. However, this wasn’t true for the length of a repository, or the count of code samples and images.

I’m not sure how practical their findings are, but I love the idea of looking at existing patterns to write better software.

The Core Infrastructure Initiative (CII) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices. Projects can voluntarily self-certify, at no cost, by using this web application to explain how they follow each best practice. The CII Best Practices Badge is inspired by the many badges available to projects on GitHub. Consumers of the badge will be able to quickly assess which FLOSS projects are following best practices and as a result are more likely to produce higher-quality secure software.

This is a great project and is receiving adoption in some circles, but given how much progress the project has made, adoption seems to be lacking. I suspect this is the case for a few reasons:

1. At 16 syllables, “Core Infrastructure Initiative Best Practices Badge Program” is a mouthful! It needs a shorter and catchier name so I can tell more people about it.

2. Checking the status of a project is a lot of work! I spent ~15 minutes adding GitHub’s Atom Editor and only got to 55%. Here’s the badge, so feel free to help finish filling it out: ). The project could benefit from more automation and autodetection.

Either way, check it out:

More information on the CII Best Practices Badging program, including background and criteria, is available on GitHub.

Why are so many people involved in open source? Well, for all of the business reasons covered before. I also think it’s joyful to get to work with people of a variety of cultures and backgrounds. Additionally, open source has given me a sense of permanence to my career, where the job I’ve taken from year to year has not.

There are a couple of different ways you can participate in open source.

…

Contributing is a form of short-term participation. You make a one-off or twice-off contribution, and then your involvement is over.

Maintaining is taking long-term ownership over a particular aspect of a project. In this equation I’ve produced, maintaining is greater than contributing both in level of reward, but also effort, commitment, and emotional involvement.

Let’s take a walk through the emotional journey of becoming a maintainer.

…

We’re all aware that open source is an increasingly valuable part of the global economy. In this talk, I hope I’ve conveyed that, emotional rollercoaster aside, maintaining an open source project can be a hugely rewarding part of your career.

When you decide to take the leap, I look forward to saying to you…

Thomas Jefferson made regular weather observations, and as a matter of fact, noted it was 76 degrees while penning the United States Declaration of Independence. The first formal collection of weather data came from super hobbyists, like Jefferson and the Meteorological Society of Palatinate, and made its way to the Smithsonian in 1849. Joseph Henry, the Smithsonian’s first secretary, created a national network of volunteer telegraph operators. In this system each operator would telegraph the wind, rain, and temperature data…

…

[Eventually], it was requested that U.S. Congress move the weather service to the Department of Agriculture. It was at this point that industries ranging from transportation, railroad companies, and the agriculture sector began demanding the data of the weather bureau. In a few years, anything that was affected by weather was dependent on the data from the National Weather Service.

Today, an industry worth US $1.5 billion revolves around weather data. Today, we also have private players and startups that provide an alternative to data from the traditional sources.

This sounds a lot like the story of open source software.

It reminds me of the book The Pirate Organization: Lessons from the Fringes of Capitalism. From the summary:

In The Pirate Organization, Rodolphe Durand and Jean-Philippe Vergne argue that piracy drives capitalism’s evolution and foreshadows the direction of the economy. Through a rigorous yet engaging analysis of the history and golden ages of piracy, the authors show how pirates form complex and sophisticated organizations that change the course of capitalism. Surprisingly, pirate organizations also behave in predictable ways: challenging widespread norms; controlling resources, communication, and transportation; maintaining trade relationships with other communities; and formulating strategies favoring speed and surprise. We could learn a lot from them—if only we paid more attention.

It doesn’t accurately reflect how people are building today anymore.

The term “open source” has become so broad as to become meaningless. I would guess at least half of my conversations with people involve the question “Wait…so what IS open source, actually?”, or realizing about 10 minutes in that we’re talking about completely different things.

…

Officially, open source is defined by a list of ten criteria, which you can read about here…Were you aware there was an official definition? I didn’t think so.

Compared to other popular concepts like “agile”, “lean”, and “organic”, the meaning of “open source” remains incredibly intact 20 years later. This is owed mostly to this definition. Everyone who uses open source shouldn’t have to be able to recite the definition of open source, let alone know it exists. Our lives are ruled by laws, bills, codes, directives, orders, and documents that most of us don’t know exist. The important part is that those building infrastructure know they exist and create sensible defaults.

Licenses are not a useful way to define modern open source anymore. They matter in as much as it matters that most startups are set up as Delaware C Corps; you want to check the compliance boxes, but the fine print is best left up to legal nerds and lawyers.

There’s a difference between becoming a common practice and becoming useless. Delaware doesn’t make C Corps irrelevant. It’s because of Delaware’s clear laws and efficient corporate legal system that make it a sensible default for most startups. The Open Source Definition and the list of approved licenses have, in some ways, done for software what Delaware did for C Corps: most people don’t have to think about it.

Technically, most projects on GitHub don’t even meet the official definition of open source (since over 80% don’t have a license). That means when we say GitHub is where people “open source” their work, we are implicitly upholding a definition that looks more like GitHub’s Terms of Service.

We’ve spent some time digging into the licensing situation on GitHub over the last few months and will be posting an updated blog post soon. Our primary conclusion is that most projects that fit any other definition of “open source”–such as multiple contributors or starred by more than a few people–have a license. In other words, the 80% of unlicensed repositories generally reflect the number of repositories that are only used by the author and maybe a few friends; these repositories tend to be things like coding exercises, personal notes or homework.

• 67% of companies surveyed actively encourage developers to contribute to open source
• 1 in 3 have a full-time person dedicated to working on open source
• 90% say open source improves efficiency, interoperability and innovation

There are still some challenges:

• 50 percent of companies surveyed have no formal policy for evaluating and choosing open source code
• Nearly 1/3 of companies have no process for identifying, tracking or remediating known open source vulnerabilities

2016 Future of Open Source Survey Results

Open source is the gift that keeps on giving … unless it destroys your business first. As many an open source vendor can tell you, it’s a slog peddling free ones and zeroes, and it’s only getting harder as the Web giants flood the world with high-quality, zero-cost software.

Web giants like LinkedIn, for example: Take a look at LinkedIn’s GitHub page, and you’ll discover the death of dozens of real or potential startups.

That’s one way to look at it. Another way is that every startup in the world can focus on creating new value, instead of wasting limited resources reinventing building blocks like messaging systems, cluster management, or key-value stores. Anyone can take this “high-quality, zero-cost software” and combine it in interesting ways to solve the problems they are uniquely qualified to solve. Unless you want an entire industry that just makes low-cost commoditized infrastructure, this seems like a good thing.

I don’t really understand why Matt started this article with this introduction. The rest of the article is generally positive. To his readers, it reflects poorly on LinkedIn (which I don’t think he was trying to do). To those that understand the open source world, it reflects poorly on him.