Sustaining Open Source Software
The ‘open source sustainability’ debate continues with yet-another-company relicensing their product away from an open source license to something proprietary. The sustainability debates seem to fall into one of several buckets:
- Commercial collaborations working diligently to identify significant projects in which to invest member resources: This discussion is best represented by organizations like the Linux Foundation (and its sub-foundations), and the OpenStack Foundation. Vendor competitive politics and market machinations rear their heads. Not everything succeeds. The Symbian Foundation failed. Hewlett-Packard shutdown the Cloud Business Unit and sold its assets after investing hundreds of millions of dollars in OpenStack. Big companies can make big mistakes.
- Individual project participants in the long tail working to manage their project efforts against other commitments and responsibilities: This discussion often involves concerns about paying people to support projects in use by companies, or project committers drowning under the load of requests for service from users to the point of burnout. It is sometimes discussed as how to make ‘open source’ a profession.
- End users just trying to get work done: Businesses consume all manner of software from the broad open source community and are occasionally surprised when bad things happen such as ‘Heart Bleed’ or the recent surprises in the Node.js community.
- Startup companies creating open source licensed software projects that are struggling with competitors and users solving their problems in the open source project community instead of paying the company for product/service. This flavour of sustainability problem is sometimes discussed as ‘the Cloud is eating open source.’ There is a collection of these companies that are trying to call foul on ‘open source’ rather than look to the mistakes they made in business model design. [I do not make that statement lightly. I’ve done enough start-up work in my career to understand how hard it is to get right. I’ve certainly lost a company in Moore’s Chasm.]
In each group, the sustainability debate is posed in terms of problems with ‘open source’ and the argument becomes how ‘open source’ has to change to account for this new software era of commercial collaboration, individual freedom, cheap software, or quick investor returns.
The overarching problem with the entire sustainability discussion is that the ‘open source’ problems are actually problems with software in general or software business practices, regardless of licensing and community collaboration, and regardless of whether the Cloud is involved. Let’s take a different view of the problem sets.
This is a long essay. I will discuss software collaboration history, how the Internet fundamentally changed the nature of the collaboration network, a couple of models and metaphors for how to think about software delivery at scale and how people really behave in a community and finally come back to the four faces of the sustainability discussion.
History is Important
We’ve collaborated on software since we’ve written software. We do this because writing good software is hard work. This goes all the way back to the early 1950s and the original work Von Neuman’s team did on the first programmable computer in the U.S. at Princeton. For almost 30 years software developers collaborated. Software was often shipped for free as part of the (large expensive) hardware base. Conferences were hubs for collaboration and exchange through waves of technological change (mainframes, minicomputers, UNIX systems). IBM SHARE in the 1950s, DECUS in the 1960s, and USENIX in the 1970s were all such hubs.
In 1980, the U.S. Congress added copyright to computer software. This provoked 18 years of experimentation with licenses to allow developers to continue to collaborate. Early work at MIT on Project Athena saw DEC, HP, IBM and others collaborating on X11 and Kerberos. U.C. Berkeley CSRG was the hub for all the BSD UNIX work that would become the heart of Sun Microsystems SunOS and DEC Ultrix. Stallman articulated software freedom and we saw the rise of the GNU projects and the experiments and evolution of the GNU Public License. The Perl world was where system administrators traded code under the Artistic License. Netscape created the first attempt at a corporate-language collaboration license with the first Mozilla license. The Apache world thrived in the wild under an Apache-named hack of the BSD license.
In 1998, all these experiments were brought together under the Open Source Definition, based on the Debian Free Software Guidelines. The Open Source Initiative was formed as caretaker of the definition, and one of its primary functions is to host the open discussions that apply the Open Source Definition to licenses to determine if a license qualifies. Anyone can participate in such discussions, but the important take away is to understand that collectively people participate in these discussions that span the breadth and depth of the past 40 years of collaboration since the U.S. Congress first thought copyright was something to apply to software. Collectively this broad, diverse group understands more about software collaboration than your cool idea about what ‘open source’ should be.
What makes the open source definition important isn’t that it was ‘new’ 20 years ago, but rather that it was the observed framework that drives collaboration best after almost 20 years of experimentation and has stood the test of this past 20 years. There are ten tenets to it. Not seven or twelve. Said differently, the open source definition is 20 years old. But software collaboration, liberally licensed since copyright was applied to software is almost 40 years old. And software-collaboration itself is basically 70 years old. The OSD is the ten tenets that best drive a particular broad system of software collaboration. Change the definition and it will balkanize the very engineering economics on which we collectively succeed.
The ever-shifting group of experience in the OSD and licenses discussion has weathered many debates. An early debate they needed to solve was OSD-aligned license proliferation and the idea that folks wanted to create a balkanized world of ‘open source’. So too with the current discussions. These broad discussions, hosted by the OSI, have enormous value. Recognize that the hosted discussions go well beyond the relatively small Board of Directors that perform the business of the OSI.
The Democratization of Software
Software licensing is at the heart of the open source definition, but that history only forms part of the discussion that is creating stress in the software world at this point. The sharing network began to change. Conferences and journals weren’t the only channels for software collaboration. Bulletin board systems were added to the mix in the early 1980s. Things begin to change in earnest in the late 1980s through the early 1990s with the rise of the Internet and then the arrival of the World Wide Web. Suddenly all the friction was pulled from the sharing network. We went from tape-sized packets and conference schedule latency to the Web in a very short span of time.
With the rise of the Web, all the things that could be digitized were digitized, all the production tooling for working in digitized media became simpler/cheaper, and all the things (books, news, video, music) were democratized. All of us could be videographers. All of us could be bloggers. Those of us with musical capabilities could publish trivially. Death to the Gate Keepers! All the channel businesses had to reinvent themselves because all the friction in the channel was stripped away when the cost of production and distribution plummeted. And we saw the rise of a new class of channel (often as a reinvention of the old channel) that was all about curation because bad writers blog too. The other thing that was democratized that we don’t discuss is the thing that was already digital — software. Anyone could now be a programmer.
Software isn’t eating the world. We are awash in software and drowning in ‘bad’ software. There’s a discovery problem. There’s a curation problem. The rising count of GitHub public repos over the past six years (4.6M in 2012, 19.4M in 2016, 96M in 2018) is symptomatic of the problem space. Anyone can be a programmer now. And so, we have a dilution problem. Good software is lost in amongst the mediocre, duplicative, and the bad. And then there’s the idea of ‘good’. What defines ‘good’ software? How do you measure ‘good’ and why? These are rapidly becoming societal problems, not just industry problems.
Cooking Software and Where You Choose to Live
I’ve been trying to find reasonable metaphors for folks to understand what’s happening in the software world from a societal perspective. Let’s start with a cooking metaphor.
Everyone knows how to fry to an egg. You can become a reasonable cook with some practice, expanding your repertoire and toolset. You may get good enough to cook for friends or tackle the Holiday meal for family. You might specialize and become very good at baking. But the world of cooking changes dramatically when you say the word ‘restaurant.’
Restaurants, regardless of whether they are 2-person taco trucks or Michelin-starred experiences, are businesses that happen to involve cooking. There is a suddenly an array of cooking skills required to consistently, reliably, repeatably deliver the same food outcome every time. There is a team with roles, and that adds all manner of communications challenges to ensure the consistent delivery of food (and experience). There are rules and regulations. Added on top of that customers need to be served, accounts payable/receivable need to be managed, (you need to spend less than you earn,) and the team needs to be hired, trained, motivated, and paid.
So too with software. There is a considerable difference between the problem sets that need to be solved to deliver software solutions consistently at scale (to large numbers of users in a community or large numbers of customers) versus bespoke solutions in the small or solutions with dozens of users not tens of thousands. These aren’t ‘open source’ problems. They’re software skillset and experience problems. These problems have everything to do with software hygiene and software engineering and apply to all software regardless of licensing regime or community versus corporate creation.
Misunderstanding the work required to deliver software reliably has been around as long as software. The point of writing a program is to solve a problem. The point of repeatable, known delivery is to be able to support the outcomes for many users. The models we build when we write software never quite map reality. There will be errors. Catching the errors early saves time and money. To find and fix the errors after the delivery, one must know how the software running on a machine was created. There is no scale in software without discipline.
Likewise, misunderstanding the work required to build community is the other big mistake I see made in these discussions of sustaining open source software.
Here’s a great community metaphor you can try. (I have used it with audiences of developers and community managers.) I observe that we all chose the neighbourhoods in which we live for personal reasons. It might be because of our (or our partner’s) commute, where our children go to school, connections with family and friends, shopping, or access to our past-times or houses of worship. We all know what our home neighbourhood feels like. Then I ask how many folks know how to report street lamps out on their street, or potholes in the road in front of their house. I get about 10% of the audience raising their hands. Then I ask how many folks organize the block party for their culture, because there’s generally a reason for a block party. I get about 1–2% of the room raising their hands.
This is the reality of communities. It’s an orders-of-magnitude problem. For every thousand users in your software project community, you’ll see a hundred issues reported, maybe ten will have a patch/pull-request, and only one of those contributors read your contribution guidelines. An open source survey in the past couple of years found that people freely using software that has an open source license still identify as members of that community even though they don’t report issues, or contribute code, or add documentation. This is why building a community takes effort and energy. You need to expand the group of users, out of which you’ll find developers hoping to do something perfectly selfish, out of which you need to encourage contributions back to the project. Freeloaders mean you’re doing it right.
This is a community dynamic. It’s societal. The dynamic doesn’t change when the community forms in a neighborhood around an open source licensed software project. One needs to set one’s own expectations as community builders with respect to the efforts to build on-ramps for selfish users and selfish developers to get to the self-less contributors. Applying an open source license to a software project doesn’t change the nature of this work to build community, just like it doesn’t change the nature of the discipline to enable scalable delivery.
Another way to think about that reality is that if you find yourself debating the nuances of the ‘Commons’, systems of governance, the roots of democracy, or voting structures, hoping that listeners will behave better once they understand the nuances, then you are part of the 1–2% in your community. Most people in your community just want to get things done for their own personal reasons. You need to invest in the work to build the on-ramps and structures to enable them to get those things done easily and find ways to encourage the innovations back to the project. Ask not what your community can do for you …
What it all means …
With these models and history in mind, let’s walk back through the list of ‘open source’ sustainability concerns.
‘Open Source’ Start-ups: I’ve written at length about how to think about liberally licensed, collaborative development as a software engineering economic imperative, and how running a software business still must be treated as running a business first and foremost. If I was to try to sum up the two posts, I would say:
- Every software development manager or product manager understands the ‘build versus buy’ decision. The engineering economics of liberally licensed, collaboratively developed software adds orders of magnitude of value capture to the discussion and turns ‘build versus buy’ into ‘build versus buy versus borrow + share.’ As engineers you must be in the position to ‘carry the fork,’ but you want to keep forks as small/narrow as possible because they quickly become expensive and can only be offset by enormous competitive advantage.
- Christensen created several litmus tests for success for new business ideas in the Innovator’s Solution (2002). Moore described the Technology Adoption Lifecycle and the Chasm (1991) and gave us a language to understand the relationship between core competency delivering core value propositions to customers, complement value add, and context. Do not confuse ‘early adopting’ users in an open source licensed project community with Moore’s ‘early adopting’ customers of product. Projects are not products. If you park an open source license on your asset that is your core value proposition to customers, you better deeply understand the solution you’re building for customers and that it is more than the ‘software.’
Your idea of running a business where your software provides a solution to customers for money needs to fit the 70-year-old software context, not the 20-year-old open source definition context for engineers collaborating on software.
The troubles start-ups are having that are re-licensing their software (e.g. Docker, Redis Labs, MongoDB, now Confluent) aren’t ‘open source’ problems. They’re business model design problems. This doesn’t mean that open source licensed software and project communities have no place in a software business toolset, but customers and business model design still need to work. VCs investing in companies building product around popular open source licensed projects need to understand that communities are not customers. The community can’t be monetized. The investment padding to ‘figure out the business model later’ isn’t going to work in this particular scenario.
‘Open Source’ End Users: A lot of the problems that are occurring are actually software consumption problems. Generally, it’s caused by developers using software from promiscuous sharing communities that have uneven hygiene and professional practices. These user-developers themselves show equally suspect practices in not understanding the software they are consuming.
This might be because they don’t understand the lack of a warranty or guarantee in any software license (open or proprietary), or they misunderstand how to judge the viability of a community (or lack thereof) around an open source licensed project, or fail to review the engineering practices, or the bug lists. The problem, however, isn’t an ‘open source sustainability’ problem simply because dipping into a repository was easy.
If I buy a meal at a restaurant and I get sick, I have some recourse as a customer of a business. If I’m buying food from the street vendors in a developing economy, I may have the greatest Anthony Bourdain infused food experience of my life, … or not. And I might have both on different days. Software transmitted disease is real.
Communities (that are sometimes simply collections of projects) where folks don’t ship product-grade software-at-scale for a living are re-learning all the old lessons about trust, hygiene, and construction discipline. The inherent promiscuity in some of these communities means we have some truly ugly infection vectors. You solve the problem with a set of software hygiene practices, and that always starts with education about the real, underlying problems. It is indeed a societal problem, but it’s a software problem not an ‘open source sustainability’ problem. The education starts with learning to wash your hands. You wouldn’t plug a USB drive you found in a parking lot into the corporate network any more than you would eat a cookie you found on the ground. Why would you trust the software you ‘found in a repo’ to run in production without some form of investigation?
The consumer also needs to understand their relationship to the IP. In a pretend world of purely commercial software, end users knew all software was 3rd party software. In a world of ‘open source,’ there are lots of different 3rd party dynamics. One of the easiest ways to understand the dynamics of an ‘open source’ solution is to ask the question, ‘Who owns this software?’ With the answer to that question, an end user can start to analyze the business support risks of using the software. Ownership gives a quick test of quality, control, re-license risk, and who gets paid for what. Again, this isn’t an ‘open source sustainability’ question, but rather a business question for 3rd party procurement and consumption.
‘Open source’ project maintainers: This is the cooking metaphor, pure and simple. You have to choose. You have to commit. Are you cooking for pleasure, or do you want to work in a restaurant? If you want to work in a restaurant, are you willing to earn the chef title, or are you happy with any of a number of other roles? If you’re happy cooking for pleasure and sharing your code and experience, you need to be able to say ‘no’ in a variety of ways. With the democratization of all the things, we see designers and writers constantly having to tell people, ‘No,’ who want to use their creative hard work for free (because it will give the creator exposure). The same goes for your software project. You have published your work under an open source license. You are allowed to say ‘no’ to additional work because it’s your work. You can choose to do work-for-hire and publish that work into your open source project. This also means you’re working for yourself. It can be done at a small scale while still ‘holding down a job.’ But it doesn’t scale well with respect to your time. The freelance programmer, designer, or writer lifestyle isn’t for everyone.
I do object to the idea that we simply need to pay ‘open source’ developers. Paying someone that can fry an egg doesn’t make them a chef. Putting someone that can cook a meal at home in a professional kitchen doesn’t make them a better cook. Understand that crowd-funding support for open source projects doesn’t scale for long. Delivering reliable software repeatably at scale takes a team. You can do that in a community, but then you need to invest to build that community, above and beyond investing in the creation of the software. If you’re a freelancer in your own community, you need to be comfortable building a community of peers, some of who may also be freelancing out of the same project.
We are seeing folks suggest this ‘freelancing’ world could be centrally managed by brokerages, providing open source sustaining support for projects for money to companies while paying the developers. I strongly suspect this won’t scale. We have the history of SourceLabs, SpikeSource, and OpenLogic to review. OpenLogic built a sustainable business, but it is not the scalable model that would keep a modern-day VC happy. Making predictable promises to customers for support will probably require employees. I’m sceptical.
None of these are ‘open source sustainability’ problems. They’re problems with how individual developers relate to projects, build communities, and organize their work.
Modern Foundations: The modern foundation as a collaboration hub is an interesting organization. There is history here as well. The basic premise in the original open source-centric foundation was to provide a neutral non-profit holder of the software IP. In doing so, vendors could reliably participate, consume, and contribute into a neutral, structured IP framework. A project in a foundation removed personal liability from the developers and provided a centre of gravity for the ‘business’ and the bank account, and the IP structure encouraged more dedicated contributions from vendors. It was a win for all involved.
Modern foundations around open source licensed projects instead are beginning to take on the role that standards organizations served in the 1990s in the software market. (This in no way suggests that standards and open source software are analogues. They are different economic tools with different economic outcomes. The organizational structures, however, serve similar purposes for collaborative competition.) For customers, there is the belief that a foundation project means they aren’t dependent on a single vendor. Just as standards never fully removed the barriers for customers, open source won’t either, but it does mitigate the risks around a dedicated solution from a single vendor. Customers signal their desire to manage lock-in risk by saying ‘open source.’ For vendors contributing projects into foundations, it is a way to signal their intent to collaborate by releasing ownership control. A vendor can still dominate a project through participation (i.e. contribution control), but by signalling the intent to share the IP, they now balance the collaboration and market gains against the threat of a fork if they push the community into an existential crisis or the risk of simply being ignored. This is similar to the politics of well-run standards organizations in the 1990s, with IBM, HP, Sun, DEC, and Unisys running particularly nuanced games.
Bringing vendor competition into the open source space creates interesting stresses in the foundations and in the projects. In the same way standards development organizations became hubs for the fight between competing standards, modern open source foundations need to manage competitive project contributions while not being seen to pick winners. Tension exists in project governance structures depending on the business tensions from contributing and competing vendors. If the foundation marketing arm is selling the overarching message well, the foundation can attract all manner of small project contributions from small companies looking to capture some brand magic, muddying the messaging and the overall architecture.
None of these problems are ‘open source sustainability’ problems. They’re business ecosystem competition problems. They don’t change because the competition happens in the social space created by an open source community. More traditional foundations had mechanisms in place to drive the competitive discussion outside the project community, but that isn’t always the goal of the IP creator. Neither does open source need to change to accommodate such competitive tensions.
Debating Open Source Software Sustainability
Many want to blame burnout, a failing business, the dumpster fire in the data centre, and the competitive landscape on ‘open source sustainability.’ If only ‘open source’ was organized differently, lives would be balanced, businesses would be booming, the software would just work, and competition headaches would be replaced with ‘coopetition’.
I don’t see this as a solvable set of problems from an open source software perspective. The open source definition is a licensing regime to allow developers to collaborate on software the way they have for 70 years. The experience embodied in the tenets of the OSD create a particular broad base of collaboration that is expansive rather than narrow.
Collaboration in communities follows well understood societal patterns. Community building takes work, regardless of whether it surrounds an open source licensed project or proprietary products or any other societal endeavour. You get out of a community what you put into it, not the other way around.
Software has been democratized along with all the other digital artefacts. As such we live in a world drowning in software of an unknown provenance and quality, and we need to solve for the problems of experience and education on the creation side so as not to continually re-learn software development and production lessons that have been realized over the past four or five decades, while also putting in place different curation systems in different communities as signalling mechanisms for end consumers. Teaching project users to wash their hands would be a good idea.
Businesses solve problems for customers for money. Open source licensed projects and collaborative communities are important tools for building out software businesses, but as with any tool, they need to be used properly and judiciously. The engineering economics of collaborative development at the heart of the open source definition isn’t a business solution for monetizing a community.
Lastly, businesses will compete for customers as they always have. Because they collaborate in a community in one node in the network of products and services that make up customer-facing solutions, doesn’t mean they do so with the same sense of community spirit you might find in a less commercial endeavour. Nor should we expect them so to do. But companies have always had a role in collaborative communities right back to the start of copyright applied to software and they acted as hubs for their own collaborative communities before then.
The trouble with ‘open source software sustainability’ ultimately is that open source licensed software has become so ubiquitous and successful in the software world in general that we often mistake software problems for ‘open source’ problems. By recognizing the underlying societal, software or business dynamic at play in each sustainability situation, we can better solve for the real sustainability problems at hand.
