Chef co-founder and former CTO Adam Jacob gave a short presentation at O’Reilly Open Source Software Conference (OSCON) 2019 titled “The War for the Soul of Open Source.” In his search for meaning in open source software today, Jacob confronts the notion of open source business models.
“We often talk about open source business models,” he said. “There isn’t an open source business model. That’s not a thing and the reason is open source is a channel. Open source is a way that you, in a business sense, get the software out to the people, the people use the software, and then they become a channel, which [companies] eventually try to turn into money.”
Companies often employ open source as a strategy to drive adoption, only to have mega corporations scoop up the software and corner the market. Jacob addressed the friction open source communities have with companies that use OSS to make billions of dollars per year running it as a service, citing Amazon Web Services (AWS) as a prime example.
Amid conflicts like these, it’s a challenge to find meaning in OSS via business. Jacob looked to organizations like the Free Software Foundation and Open Source Initiative but could not get on board with the methods and outcomes they pursue through their efforts.
He concluded that what is left is the people at the heart of OSS, who improbably come together with an overlapping sense of shared values and purpose.
“Each of us are a weird different shape, struggling to find our path and yet open source software gives us this ability to gather together around this resource that we turn from being scarce to being infinite,” he said.
“Look at your own desires, look at your own needs and the things you want in your own life. Then go out and find and build and steward communities with other people who share those values and who will embrace your purpose, and sustain each other. Because that is the true soul of open source.”
In December 2018, Jacob launched the Sustainable Free and Open Source Communities (SFOSC) project to advocate for these ideas. Instead of focusing on protecting revenue models of OSS companies, the project’s contributors work together to collaborate on writing core principles, social contracts, and business models as guidelines for healthy OSS communities.
“I believe we need to start talking about Open Source not in terms of licensing models, or business models (though those things matter): instead, we should be talking about wether or not we are building sustainable communities,” Jacob said in a post introducing the project. “What brings us together, as people, in this common effort around the software? What rights do we hold true for each other? What rights are we willing to trade in order to see more of the software in the world, through the investment of capital?”
Check out Jacob’s presentation below for a 13-minute condensed version of the inspiration behind the SFOSC project.
Feross Aboukhadijeh, maintainer of StandardJS, has formally ended the funding experiment he started lasted week, which inserted ads in the terminal whenever Standard 14 is installed.
Although the experiment met widespread aversion, it successfully captured public attention and put a spotlight on the critical need for a viable model of funding open source infrastructure. It also uncovered some intense presuppositions that developers have when it comes to protecting their workflow in the terminal.
“If nothing else, it’s nice that funding forced open source ‘consumers’ – folks who enjoy the benefits of open source software without ever contributing anything back – to reconsider their relationship with open source,” Aboukhadijeh said. “I think we successfully pushed back against the entitlement to free labor that is pervasive in the interactions that open source consumers have with maintainers.”
Supporting work with advertising is nothing new, but the shock of seeing ads in the terminal activated an urgency in the open source community to collectively brainstorm and consider new approaches.
“While I didn’t like the approach, I understood the goal,” ESLint creator Nicholas C. Zakas said. “There is little involved in mindlessly typing ‘npm i’ and getting something for free. This experiment at least broke people out of that mode, even if only momentarily.”
Google Chrome engineer Chris Palmer said he saw Aboukhadijeh’s experiment as “a live demonstration of the fact that it’s very very hard to get people to pay, in any way, for information goods, which are indeed scarce. It has been as delightful and as bracing as it always is.”
In his recap of the
funding experiment, Aboukhadijeh contends that the phrase “open source sustainability” isn’t ideal, because maintainers are often simply subsisting, as opposed to thriving, on the few donations they receive, despite creating millions of dollars of value for the companies that use their work.
“The dirty secret of open source is that much of it is powered by maintainer guilt,” Aboukhadijeh said. “A lucky few manage to land day jobs that allow them to work on open source. But most folks have to be more creative – squeezing in time after work, secretly doing open source maintenance at work, or opting out of normal society completely.”
Aboukhadijeh is particularly concerned about finding solutions for the “invisible” maintainers of transitive open source dependencies, packages that no one installs directly:
But reliable, error-free transitive dependencies are invisible. Therefore, the maintainers are invisible, too. And, the better these maintainers do their job, the more invisible they are. No one ever visits a GitHub repository for a transitive dependency that works perfectly – there’s no reason to do so. But a developer investigating an error stack trace might visit the repository if for no other reason than to file an issue. At least then there’s a small chance they’ll see the maintainer’s plea in the README.
We need solutions that work for these folks too.
Although this particular funding experiment did not prove to be successful, Aboukhadijeh said he has more sponsors who are interested and more experiments in the works that he is excited about.
“Maybe ads aren’t the answer – fine,” he said. “But telling maintainers to bury their appeals where no one bothers to look is not the answer, either.
“Approximately 100% of the Fortune 500 use open source code. Maintainers are just starting to wake up to our own power. Expect to be surprised. This certainly won’t be the last open source funding experiment.”
“I think that the current model of sustaining open source is not working and we need more experimentation,” Aboukhadijeh said. “This is one such experiment.” He developed a module that inserts an ad whenever Standard 14 is installed. Sponsorship funds are designated to pay for maintainer time, which he defined as “writing new features, fixing bugs, answering user questions, and improving documentation.”
Aboukhadijeh is a prolific developer who has authored more than 100 packages on npm that are downloaded 100+ million times per month. Standard is his most popular open source project and is used by high profile projects and companies, including Node.js, npm, GitHub, Automattic, and many more.
Aboukhadijeh said his goal with the experiment is to make Standard and other open source projects healthier.
“For complex reasons, companies are generally hesitant or unwilling to fund OSS directly,” he said. “When it does happen, it’s never enough and it never reaches packages which are transitive dependencies (i.e. packages that no one installs explicitly and therefore no one knows exists). Essentially, we have a public good which is consumed by huge numbers of users, but which almost no one pays for. Fortunately, there exists a funding model that usually works for public goods like this – ads.”
Here is an example of the LogRocket ad that was part of the initial experiment:
While some developers communicated support for open source maintainers to monetize their projects in whatever way they choose, the majority of feedback on GitHub, Hacker News, Reddit, and social media strongly criticized this particular approach.
William Hilton, developer at Stoplight, speculated on the consequences of this type of advertising becoming a popular funding model:
I do worry that npm install will just become a long trail of banner ads though eventually and it won’t scale. Because if every npm package adds ads, the noticeability of each ad will diminish. (Interestingly, the most valuable “realestate” will be packages whose banner is displayed last, so if it becomes a literal “race-to-the-bottom” people might add sleep statements to their post-install scripts so they are displayed nearest the bottom. What a dystopian installation experience!)
He also noted that Yarn blocks the output of post-install scripts, which in this case would serve as built-in ad-blocking. Yarn’s maintainer chimed in on the thread with more context.
“As maintainer of Yarn, I’m strongly against this pattern, although not for the reasons you might think,” Maël Nison said. “Post-install scripts deoptimize packages and break workflows.
“Yarn already doesn’t print the build logs unless they make the installs crash, so this post-install script wouldn’t have any visible effect for our users. Still, I value the health of the ecosystem a lot, both from the point of view of maintainers and users, and I would be happy to discuss how we could satisfy this use case in a more integrated and less intrusive way.”
Since this is a newer experiment and hasn’t gone mainstream, it’s not clear whether npm may decide to block all methods of serving advertisements through the terminal in the future. A new module called No CLI Ads was created in response to Aboukhadijeh’s funding module. It blocks ads from appearing in console output. npm-adblock is an alternative that functions in a different way. The existence of simple, albeit inconvenient, ways of blocking these types of ads may be all that is necessary to dry up any potential revenue stream.
Feedback on this experiment demonstrates that there is wide support for finding a solution to the problem of open source funding, but most agree that terminal ads is not a viable option. In fact, many commenters identified this approach as the most annoying thing that a package maintainer can do, apart from removing the package. Developers do not wish to be spammed while installing a dependency. One commenter describes his terminal as “the one last stronghold” and “haven of peace” that doesn’t serve ads from corporate overlords.
“Selling ad-space is not innovative,” developer Matthias Hogerheijde said. “And it’s particularly unhelpful in my logs. For me, the issue is more that I don’t want stuff that doesn’t help me in my logs. I wholeheartedly agree with putting your ‘supported by company X’ in the readme. That helps me understand, it does resonate with me when I see certain companies donating money to OSS. I, too, want to live in a perfect world where every developer can live, pay rent and only work on projects they like. That perfect world for me does not include ads in my terminal.”
Reddit commenters took humorous jabs at the idea, penning sample ads that interrupt the build process:
Linode Pulls Sponsorship from Standard’s Terminal Ads Experiment
Standard.js users who were unhappy with the ads in their terminals complained to the sponsors and Linode decided to remove its ad from the experiment.
“We reconsidered after reflecting on the developer community’s reaction,” a Linode representative said on Twitter. “We still passionately support open source software along with @feross, but we’ll be more careful about experimenting in the future while continuing to innovate.”
Prior to pausing the experiment, Aboukhadijeh reported he had raised $2,000, enough to fund five days worth of his time to release Standard 14.
“If we are able to raise additional funds, the next thing I’d like to focus on is out-of-the-box TypeScript support in StandardJS (one of the most common feature requests!) and modernizing the various text editor plugins (many of which are currently unmaintained),” Aboukhadijeh said. “If others in the community are interested in taking the lead on any of these issues, I’d like to direct some funds to you.”
The experiment isn’t entirely off the table, since it seems to have met one of Aboukhadijeh’s immediate objectives, despite annoying (and in some cases infuriating) the developer community.
Four days ago, Standard locked the GitHub thread discussing the new funding model after it became too heated. The project’s maintainers are now evaluating this iteration of the experiment, but the discussion extends beyond the simple question of whether developers like ads in their terminals. A new thread on the project’s repo, titled “What’s wrong with Open Source right now?” has diverted some of the negative feedback into a broader, more productive discussion.
The experiment has reignited important conversations about the sustainability of open source and where project maintainers want to see it go in the future. In a recent tweet, Aboukhadijeh shared a link to particular situation that one maintainer faced in supporting a free syntax highlighting library.
After receiving urgent comments and emails following a release that had errors causing dependencies to break, Ivan Sagalaev, the original author of highlight.js, aptly summarized the current state of the relationship between businesses and open source projects:
Dear fellow engineers, please take this build hiccup as an opportunity to explain to your particular business people that their entire intellectual property is a thin layer on top of a shaky foundation of open-source code lazily maintained by hobbyists or paid for by other businesses having their own goals in mind.
If they really want stability they have to invest in it by, for example, hiring engineers to deal with myriad of dependencies, maintain local stable forks, contribute patches upstream, or whatever — the key point is that it should not look like it ‘just works’ on fairy dust.
In this episode, John James Jacoby and I are joined by Jonny Harris. Jonny describes how he discovered WordPress and some of the core projects he’s been working on including, Site Health Checks, fatal error protection, and Multisite. We discuss WordPress’ focus on users vs developers in recent years, Jonny’s experience contributing to core, and his thoughts on a WordPress governance model.
WordPress Is Borked So Enjoy This Glorious Plant That’s Taking Over the Internet
WP Engine Launches DevKit Open Beta
Drupal Gutenberg 1.0 Released, Now Ready for Production Sites
BuddyPress 5.0 to Update Password Control to Match WordPress
Episode 356 Transcript
Next Episode: Wednesday, June 19th 3:00 P.M. Eastern
Subscribe to WordPress Weekly via Itunes
Subscribe to WordPress Weekly via RSS
Subscribe to WordPress Weekly via Stitcher Radio
Subscribe to WordPress Weekly via Google Play
Listen To Episode #356:
Podcast: Play in new window | Download (Duration: 1:15:20 — 59.1MB) | Embed
Subscribe: Apple Podcasts | Android |
GitHub has launched a new Sponsors tool that allows open source developer to receive financial support. The program is rolling out slowly and currently has a waitlist for open source contributors or maintainers who want to join.
For the first year developers are in the program, GitHub will cover all the payment processing fees and has pledged to match all contributions up to $5,000.
Individual developers participating in the program can customize the funding options displayed when potential supporters click on the Sponsor button. They can add links to other popular funding services, such as Open Collective, Community Bridge, Tidelift, Ko-fi, and Patreon. Open source projects an also specify funding models for contributors by adding a .github/FUNDING.yml file to the project’s master branch.
GitHub has an advantage over other competing funding services by having its Sponsorship model embbeded in the GitHub workflow where much of the work actually takes place. However, this also raises concerns about how sponsor expectations may influence a project’s development.
“You can now sponsor developers as a seamless part of your familiar workflow,” GitHub open source project manager Devon Zuegel said in the announcement. “When a contributor answers your question, triages your issue, or merges your code, you can head to their profile—or simply hover over their username—to sponsor their work.”
Sponsorship is a somewhat subjective term and GitHub isn’t defining what it means here in the context of marrying it to a contributor’s workflow. For some, it may mean a no-strings-attached donation. For others, the idea of sponsorship always comes the expectation of a return on an investment.
Ruby on Rails creator and Basecamp founder David Heinemeier Hansson was one of the most prominent to raise concerns about GitHub’s Sponsors program on Twitter. He sees it as “a grave risk to open source.”
“’Why haven’t you fixed my issue yet!? I sent you $10! I demand you honor your obligations here. I paid you,’ welcome to small-donation open source 2019,” Hansson said.
“I’m sure GitHub had all the right intentions here. And I’m sure this will work out well for a select few developers who will amass enough donations to ignore individual claims to their time. But I think it’s a grave risk to the culture of open source.”
Hansson referenced a recent keynote he delivered at RailsConf 2019 titled “Open source beyond the market,” challenging those whose initial reactions are simply that “donations are a good thing.” Bringing the concept of sponsorship a into the workflow introduces a transactional nature to the work, with unavoidable marketplace expectations that can complicate a project’s development.
“The marketplace norms are hard to escape,” Hansson said in his keynote. “They seep into our unconsciousness. There are plenty of open source users who think themselves less as a recipient of a gift and more like customers with warranty claims, that they’ve done the makers of said open source software a great honor by merely choosing to use their thing.
“In fact, it’s kind of a natural extension of a society that worships consumerism above little less. A natural extension of ‘the customer is always right,’ of the adversarial relationship between buyer and seller.”
Others have expressed more specific concerns, such as Microsoft’s GitHub becoming the dominant payment platform for open source developers, sponsors receiving priority consideration in issues and PRs over user and project needs, and developers deliberately introducing bugs in order to solicit donations.
Pia Mancini, co-founder of Open Collective, wrote a response to the concerns that people were sending her way on Twitter.
“I am really happy to see such an important player in the ecosystem helping out with the problem of sustaining open source,” Mancini said. “Sustaining our commons is an effort that requires everyone to contribute. I am glad to see Github come on board.”
This idea of the sustainability of open source and the “tragedy of the commons” is one that Hansson and many others reject, but it is one that is commonly embraced by copyleft advocates. It works for Open Collective’s business model, but comes with its own flavor of reciprocity. Open Collective is distinct in that its funding service is removed from the direct workflow of software development, instead of deeply integrated like GitHub’s Sponsors tool.
Mancini said that her company can “happily coexist with GitHub Sponsors” because of Open Collective’s chief differentiators. It was built for projects, not individuals. It offers full transparency about where funds come from and how they are spent. The company also manages the paperwork and tax forms required for fiscal sponsorship.
“Open Collective is for funding projects as opposed to individual maintainers,” Mancini said. “We strongly believe in supporting communities as a whole, as well as the individuals that make up that community. This helps with ensuring more diversity, and less concentration of power and decisions on one maintainer.”
She also cautioned against GitHub trying to swallow up too many aspects of the open source community and injecting its own corporate interests. She hints at a line that the company has not yet crossed but many are still wary of what Microsoft plans to do with GitHub.
“Of course, there’s risk: centralization and lock-in are very risky for communities,” Mancini said. “GitHub is Microsoft, which has its own metrics in mind, and it will be difficult for them to be independent, regardless of the good faith of the folks involved.
“Attempting to own all aspects of the open source community is a harmful strategy. So far, I don’t think GitHub is trying to do this. They are in a position to help, and they are open to collaborating with existing players.
“Does it compete with Open Collective? To some extent. But our growth has never been primarily driven by individuals giving to individuals, but by companies giving to projects. GitHub Sponsors does not solve the need sponsor companies have for invoices and a legal entity to engage with for their vendor systems and documentation requirements.”
GitHub’s intentions may simply be a recognition of what open source software has matured to become – a driving force of innovation in all industries and an effort worthy of financial support. Giving developers an easy way to receive some reward for their contributions seems rather innocuous, but the concern is that Microsoft cannot foresee the long term consequences of its sponsorship implementation inside GitHub’s workflow. Open source project maintainers who pressed GitHub for more consideration of open source workflows may get more than they bargained for.