As a long-time developer and advocate of open source software I’ve taken to write this post partially as a follow-up to a post by Dries Buytaert1, but also to share and add to the current dialogue around open source sustainability. The sustainability of open source has been something I’ve been passionate about for nearly two decades focusing on how the full ecosystem from developers to documentarians, bug reporters, security team members, marketers, business leads, and more can all thrive and build careers in open source. Relatively speaking open source is still new and the economics behind it are not yet fully matured. There are gaps in our collective knowledge and frameworks. I offer this perspective as an option to learn from another industry picking and choosing the best bits and refining those that are less than ideal. The goal to offer new suggestions towards the sustainability of open source as an industry and as software.
Lessons from the Music Industry
In 1913 the American songwriter Victor Herbert walked into the Shanley restaurant in New York City and heard of one his songs playing during dinner service. At this time it was considered rude to play the music of a living composer without their permission, but it wasn’t illegal. Although you may not have heard of Victor Herbert’s name it is highly likely that you have heard his music in some variation. A few of his most famous works include “Old New York” and “Babes in Toyland” and he is still considered one of the most influential composers. Herbert sued the restaurant2 and won a landmark case that set a precedence of compensation for the composers, artists, and publishers of music that continues to this day. The result of that lawsuit created what is today known as the American Society of Composers, Artists, and Publishers or ASCAP3.
ASCAP in their own words:
ASCAP is a membership association of more than 720,000 songwriters, composers and music publishers. We uphold the value of our members’ music, and help them thrive alongside the businesses that use their music every day. We license over 11.5 million ASCAP songs and scores to the businesses that play them publicly, then send the money to our members as royalties4.
It is an important distinction here to note that ASCAP represents the music creators post creation and is not a music label (BMG, Sony Music, EMI, Defjam, etc.) who work pre-creation. The most notable way many interact with ASCAP these days is through services such as Spotify, Pandora, Apple Music, Youtube, and more.
I am not of the belief that the ASCAP model is one to copy wholesale on the Open Source community, but I do believe there is a significant amount we can learn from this 100+ year old model that has helped lead to a rather robust, although contentious and controversial, music industry.
Why do we need to think about this?
Open Source has won across the board and it has won because it has proven itself to be the most innovative and cutting edge solution. This innovative edge is tied to the permissive licensing that provides the freedom to take, deconstruct, enhance, and rebuild the software all without asking permission, paying a fee, or even a need to notify the original author7. I believe that it is in our best interest to preserve this key tenant of open source - it has exponentially accelerated the growth of software and hardware over the past few decades. However, in the past decade as open source has consumed the world and laid the foundations of multi-billion companies this permissive licensing and freedom has been misconstrued and in some cases exploited by companies that have only focused on the first part of that path - taking.
In a culture of Makers and Takers - a concept laid out well by Dries Buytaert in his excellent blog post - we are beginning to see too many takers. The most notable example of too many is OpenSSL.
You may remember OpenSSL from a memorable security incident - Heartbleed - that took down and made most of the internet vulnerable and cost an estimated $500 Million to clean up. It’s easy to think that Heartbleed was a software bug, but it is more a case of failed software economics wherein the software used to encrypt millions of websites around the world was maintained on a budget of less than $50,000 a year at the time that heartbleed was discovered8.
Sadly, this is not the only example:
Billions of devices around the world use cURL to manage software and security updates. Increasingly many of these are consumer IoT devices purchased from sites like amazon.com. Despite being a critical piece of software it is maintained by a single developer and a handful of volunteers.
NTP (Network Time Protocol)
A critical part of nearly all networked devices (read: everything built these days) and cloud systems - is maintained by a handful of volunteers and a small budget.
This problem is not simply about the financial matters of paying the creators and makers of the software for their ideas and talent. Software lives in a very different realm than music: it is living, breathing, and is never truly complete - it must be maintained. Poor maintenance has a direct correlation to security concerns and as software becomes more ubiquitous so do the security concerns. If we do not tend to these software concerns not only will we stifle our innovation by letting our foundation rot from under us, but we will also leave ourselves vulnerable to another heartbleed scenario.
What has been tried
There are a lot of models out there and there is a lot of good work being done, but we haven’t solved the problem yet. A few examples of the current OSS business and funding models include:
- Freemium/Service and Support
- Service wrappers
- Automattic (WP)
- Open Collective
- Software Conservancy
- Dependency Review for directed crowdfunding
- Linux Foundation
- Drupal Association
- Network Time Foundation
Several of these models have worked - Redhat is a billion dollar company, Linux Foundation is doing great work, there is great momentum with Open Collective, and I personally like Tidelift’s approach. I also like to think we’ve done some really great work at the Drupal Association, but we along with the industry have a lot of work to do.
These models only go so far - not every piece of open source software will become an independent industry that warrants a service/support wrapper or grow to have a membership based foundation/Association. Crowd-sourcing approaches help bridge this gap, but can’t cover all. Increasingly software relies on other software - known as dependencies and at some point these dependencies are used so ubiquitously that they both become both critical and obscured. Left pad9 was an example of a piece of software that was so ubiquitous it became obscured - or in short its ubiquity created obscurity.
Sadly, when a piece of software reaches this level of ubiquity or is obscured too often it is assumed that it’s being maintained - when in reality no money, time, or contribution is passed to it. Growing more frequent these obscured dependencies are becoming foundational - leading them to be more akin to unmaintained public goods such as roads, water, waste management, and more. I think there are very strong arguments to be made that some software has crossed into the realm of public goods and should be cared for in a similar manner. However, this will not be enough. We need new models.
Lesson learned from the Music Industry
Although a controversial industry I think there are lessons we can learn from the industry, specifically - ASCAP.
To oversimplify how ASCAP works they offer memberships to websites/apps, television & movie production, DJs, gyms, bars, and more providing both blanket licenses for music or a specific license for a piece of music (ex. A license for a specific song in a movie). In short they are brokering a relationship between over 720,000 makers and millions of takers, which helps to fund the makers’ livelihoods and allows them to make a living off of their art.
As the music industry is rife with controversy, just another point of clarification. It was the Recording Industry Association of America (RIAA) that indiscriminately sued individuals for downloading music, not ASCAP10. ASCAP is not perfect11, but let’s focus on the goals of the model and not yet on the various nuances of how it’s applied.
As an intermediary ASCAP acts between the makers of the music and the listeners (i.e. takers), helping to ensure that the makers get paid for the entertainment and enjoyment they provide. While not a perfect model, it’s been in existence for over 100 years and is credited with building a healthy ecosystem of creators and listeners. More importantly they do this across the various layers of music creation - Writers and Publishers. Writers are responsible for the creation of the music and publishers for the business of its distribution.
It is not a far stretch to show a correlation in the open source world. Software is not built in a vacuum - there are many activities around software development including documentation, bug reporting, bug fixes, security teams, advocacy, support, and much, much more. Similarly in music there are lyricists, vocalists, musicians, song writers, beat makers, and more. For over a hundred years ASCAP has built models to help everyone involved make a living from their work.
Here are a few items that I believe carry over and that we can learn from:
Streaming and Broadcast license:
ASCAP issues bulk licenses to companies that use music - examples would be DJs, clubs, bars, spotify, etc. They provide a method for these companies to broadcast or stream music that supports the makers behind the music without requiring each company to maintain a list of every song played and remit payment to every artist directly
Fortunately, we have this much easier in the OSS world. Much of the world’s software is now in package managers or repositories such as NPM, PyPi, Composer, Packagist, and more. Increasingly, these are centralized repositories that developers or automated build processes are pulling from multiple times a day. It’s easy to envision a model of monitoring and tracking the uses of each package, tabulating the amount of use per user, company, or platform and requesting contributions back to said project commensurate with how the software is being utilized. Consider the analytics of software use that Github, Gitlab, and Atlassian have today.
Currently we have really great software such as Openhub12 that highlights the activity of an open source project, but we don’t have a site that demonstrates the reverse. The use of Open Source by organization alongside their contributions & support.
The ASCAP synchronization license, often paired with a Performance Rights Organization (PRO)13 provides a method to take a very specific song and pair it with your film/media (i.e. synchronize it). This is a method for the maker of a film to be creative with a song and create a, hopefully, symbiotic relationship with the music maker.
As film is to music, cloud can be to OSS. One of the most recent examples is that of Amazon and MongoDB. Amazon launched a version of MongoDB on its cloud infrastructure, which was a great use of software and hardware for customer benefit. However, little of the revenue generated was making it way back to the maker. In response MongoDB created the Server Side Publishing License (SSPL) to prevent the use of their software without permission14, and Amazon responded with the creation of DocumentDB15 as an end run.
SSPL may not be the correct vehicle to build a symbiotic relationship16, but it highlighted that the software industry does not currently have an equivalent of a synchronization license or PRO license. The industry is struggling for a symbiotic relationship between cloud providers and software makers.
Dragons lay in the mist
This idea is not without its problems - it is incredibly complex on both sides.
Music might be the creation of one or a small handful of individuals whereas open source software is often created by tens or hundreds of thousands of individual contributors - determining who should be paid for how much contribution is a daunting and potentially impossible task. As an example - Drupal is built, maintained, and supported by over 100,000 individual contributors every year when we count those writing documentation, responding to issues, reporting bugs, presenting at conferences, fixing bugs, suggesting new ideas, maintaining infrastructure, addressing security reports, and writing software - and this is just to name a few of the overall tasks involved.
A new piece of software often uses a significant number of dependencies. Similar to a disc jockey that mixes, remixes, and overlays multiple songs together to create something new. For example, Girltalk17 used over 300 song samples to create 14 new songs for the album Feed the Animals18 - software is similar. It’s not uncommon for a new application or website to use upwards of 200-300 dependencies when the entire stack is compiled together and deployed. Fortunately, OSS licenses have made this complex task incredibly easy, but while the licenses provide ease of use they provide no method for maintenance or upkeep - that is left to the user.
Finally, and not to be overlooked, the ASCAP model relies upon copyright and litigation or the threat of litigation in order to keep the membership base full. This is neither desirable and often not legally possible within the open source community. However, we do have a model that could work.
Practical implementation of the concept in OSS
Merging the ASCAP model with an extension of a model proposed by Dries’ post (“Model 3: Centralization of Open Source Governance) and the suggestion of “encourage end users to offer selective benefits to Makers,” I think we have an opportunity here to extend a credit system on a much more grand scale through the use of our package and dependency managers.
Tidelift is a great organization that provides and application that will review your software and search its dependency tree to give you a simple read out on the open source software in use. Then they provide a straight-forward membership model to help support those projects. Simple, easy, and awesome.
Package and build management platforms give us the best option to experiment. Currently most package systems, like Composer or NPM, download software anonymously, but, similarly to NPM’s private repos, only a simple update is needed to tag a user/organization. This would allow aggregation and tabulation of software use, including the full dependency tree. These tags can then provide information back to the development agencies and end-users to help them support accordingly.
A similar equivalent in the music industry is Spotify for Business. The business signs up for a single payment to play music in their venue, Spotify via ASCAP or BMI (in the U.S.) distributes payment to the various makers based on what was streamed.
We don’t need to go the exact route as the music industry and start filing lawsuits and locking down all software through copyright, trademarks, and restrictions. We’ve seen this route before and we know that it kills innovation and can stagnate an entire industry. However, we can’t let our foundations go unmaintained.
This is not a new idea or model - Open Collective, SPI, OSI, and others currently provide a mechanism for this and I applaud Github’s recent decision to include Sponsorship directly on a project’s page19, including Open Collective, Community Bridge, Tidelift, Ko-fi, and Patreon. However, most models require us to choose a single project to sponsor instead of an automatic monitoring of what is in use and a method to support the entire tree of dependencies. Tidelift is a bit different in that it will search a dependency tree and report on what software is being used - automating the chore of identifying what projects to sponsor.
Imagine if you are a development agency that builds thousands of pieces of software with each piece consisting of hundreds of dependencies. The permutations of what software is used where would be astronomical and difficult to track. How you decide where to allocate your time and funding for these external software dependencies?
I fear that the complexity of this has led many to inaction.
Where do we go from here?
There is no single solution - it will only be solved through a series of collective actions. First we need to continue with what we have:
- Contribute time, expertise and knowledge to Open Source
- Financially support the Foundation/Associations behind any given project
- Support the collective organizations:
- Open Collective (Thank you Github for making it easier!)
- Open Source Initiative (OSI)
- Software in the Public Interest (SPI)
- Linux Foundation
- And these are only a few...
- Get Involved by attending events such as:
- Sustain OSS (https://sustainoss.org/)
- Open Core Summit (https://opencoresummit.com)
- Most importantly spend your money wisely - choose to work with companies that contribute and/or participate in open source
But we need to continue to explore options. New licensing and funding models have to be explored and experimented with. ASCAP, BMI, PRO, and other similar organizations in the music and film industry have made this process simple, which has led many to opt-in to a simple membership model that supports the industry (i.e. purchasing a Spotify, Pandora, Youtube, Apple Music membership). In addition this model is repeated worldwide and in similar industries such as the screen actors guild (SAG). Open Source Communities need to look for ways to ease contribution and support while also maintaining the freedom and flexibility that open licensing provides.
As daunting as the challenge may be we shouldn’t be dissuaded. We must look for solutions to these problems. There is an enormous industry being built off open source and as the cloud wars roar and software becomes more packaged we will have an increasing disconnect between the developers of the software and the users - this will leave us both insecure and on deteriorating grounds. We need to explore new models, public/private partnerships, and methods to improve the sustainability of open source.
- 1. https://dri.es/balancing-makers-and-takers-to-scale-and-sustain-open-source
- 2. https://en.wikipedia.org/wiki/Herbert_v._Shanley_Co.
- 3. https://www.ascap.com
- 4. https://www.ascap.com/about-us
- 5. https://opensource.com/business/16/5/2016-future-open-source-survey
- 6. https://tidelift.com/subscription/managed-open-source-survey
- 7. https://en.wikipedia.org/wiki/Open-source_software
- 8. https://en.wikipedia.org/wiki/Heartbleed#Root_causes,_possible_lessons,_and_reactions.
- 9. https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/
- 10. https://www.eff.org/wp/riaa-v-people-five-years-later
- 11. https://www.eff.org/cases/us-v-ascap
- 12. https://www.openhub.net
- 13. https://www.ascap.com/help/career-development/a-checklist-for-using-music-in-film
- 14. https://www.mongodb.com/press/mongodb-issues-new-server-side-public-license-for-mongodb-community-server
- 15. https://www.theregister.co.uk/2019/01/10/amazon_documentdb/
- 16. http://lists.opensource.org/pipermail/license-review_lists.opensource.org/2019-March/003989.html
- 17. https://en.wikipedia.org/wiki/Girl_Talk_(musician)
- 18. https://en.wikipedia.org/wiki/RiP!:_A_Remix_Manifesto
- 19. https://github.blog/2019-05-23-announcing-github-sponsors-a-new-way-to-contribute-to-open-source/