Posted on

ESLint Maintainers Share Challenges of Funding Open Source Utilities through Sponsorship

ESLint, one of the most popular JavaScript linting utilities, quickly eclipsed more established early competitors, thanks to its open source license. The clear licensing enabled the project to become widely used but did not immediately translate into funds for its ongoing development. Despite being  downloaded more than 13 million times each week, its maintainers still struggle to support the utility.

A little over a year since launching ESLint Collective to fund contributors’ efforts, the project’s leadership shared some of the successes and challenges of pursuing the sponsorship model. One effort that didn’t pan out was hiring a dedicated maintainer:

This was a difficult thing for the team to work through, and we think there’s an important lesson about open source sustainability: even though we receive donations, ESLint doesn’t bring in enough to pay maintainers full-time. When that happens, maintainers face a difficult decision: we can try to make part-time development work, but it’s hard to find other part-time work to make up the monthly income we need to make it worthwhile. In some cases, doing the part-time work makes it more difficult to find other work because you are time-constrained in a way that other freelancers are not.

One somewhat successful experiment ESLint explored is paying its five-person Technical Steering Committee (TSC), the project leadership responsible for managing releases, issues, and pull requests. Members receive $50/hour for contributions and time spent on the project, capped at a maximum of $1,000/month. The cap prevents TSC members from spending too much time on the project in addition to their day job so they don’t get burned out.

The team reports that this stipend arrangement has worked “exceedingly well” and contributions have slowly increased: “There is something to be said for paying people for valuable work: when the work is explicitly valued, people are more willing to do it.”

On larger projects like WordPress, corporate contributions are critical to its ongoing development. In recent years, the Five for the Future campaign has helped compensate many contributors as their employers pay them a salary while donating their time to work on WordPress.

Some of the major advancements in WordPress require an immense investment of time and expertise. It’s problem solving that requires working across teams for months to build complex solutions that will work for millions of users. That’s why you don’t see armies of people building Gutenberg for free. Much of the development is driven by paid employees and might not otherwise have happened without corporate donations of employee time. Automattic, Google, Yoast SEO, 10up, GoDaddy, Human Made, WebDevStudios, WP Engine, and many other companies have collectively pledged thousands of hours worth of labor per month. The diversity of companies and individuals supporting WordPress helps the project maintain stability and weather the storms of life better.

Smaller open source projects like ESLint rarely have the same resources at their disposal and have to experiment. Summarizing the one-year review of paying contributors from sponsorships, the team states: “Maintaining a project like ESLint takes a lot of work and a lot of contributions from a lot of people. The only way for that to continue is to pay people for their time.”

When even the most popular utilities struggle to gain enough sponsorships, what hope is there for smaller projects? Many utilities that have become indispensable in developers’ workflows are on a trajectory towards becoming unsustainable.

“Unfortunately, utilities like these rarely bring in any meaningful amount of money from donations, no matter how widely used or beloved they are,” OSS engineer Colin McDonnell said in his proposal for a new funding model. “Consider react-router. Even with 41.3k stars on GitHub, 3M weekly downloads from NPM, and nearly universal adoption in React-based single-page applications, it only brings in ~$17k of donations annually.”

McDonnell proposed the concept of “sponsor pools,” to fund smaller projects that are unable to benefit from existing open-source funding models. Instead of making donations on a per-project basis, open source supporters could donate a set amount into a “wallet” every month and then distribute those funds to projects they select for their sponsor pools. The key part of the implementation is that adding new projects to the pool should only take one click, reducing the psychological friction associated with supporting additional projects.

McDonnell suggested that GitHub is the only organization with the infrastructure to implement this model as an extension of GitHub Sponsors. One commenter on Hacker News proposes that Sponsors and the idea of “sponsors pool” could exist in parallel.

“I believe that there’s a meaningful difference between being the patron of a developer and feeling like you’re backing a creator with feelings and a story and a family… and wanting to be a good citizen that has an approved list of projects that I benefit from and want to support,” Pete Forde said.

“I can sponsor Matz, get his updates and feel good about knowing I am counted as a supporter AND set aside $$$ per month to contribute to all of the tools I use in my projects simply because it’s the right thing to do and I want those projects to exist for the long term. They are completely different initiatives. Patreon vs Humble Bundle, if you will.”

Tidelift is another concept that was highlighted in the HN discussion. It has a different, unique approach to funding open source work. Tidelift pools funds from the organizations using the software to support the maintainers.

“I maintain ruby grape, a mid-sized project,” Daniel Doubrovkine said. “We get $144/month from Tidelift. As more companies signup for corporate sponsorship the dollar amount increases. It’s a pool.”

Snowdrift takes a more unusual approach to pooling sponsorships where patrons “crowdmatch” each others donations to fund public goods. It runs as a non-profit co-op to fund free and open projects that serve the public interest.

Flossbank is more specifically targeted at funding open source projects and takes technical approach to ensuring equitable contributions to the the entire dependency tree of your installed open source packages. The organization claims to provide “a free and frictionless” way to give back to maintainers. Developers can opt into curated, tech-focused ads in the terminal when installing open source packages. As an alternative, they can set a monthly donation amount to be spread across the packages they install.

No single funding model is suitable for all projects but the experiments that pool sponsorships in various ways seem to be trending, especially for supporting maintainers who may not be as skilled in marketing their efforts. The conversation around supporting utilities continues on Hacker News. WordPress developers who depend on some of these utilities may want to join in and share their experiences in funding small projects.

Posted on

StandardJS Pauses Experiment with Ads in the Terminal after Linode Pulls Sponsorship

Feross Aboukhadijeh, maintainer of the StandardJS library, a JavaScript style guide, linter, and automatic code fixer, launched an experiment last week that places ads in the terminal in order to fund development. The experiment has since been paused after receiving negative feedback from the developer community, causing Linode, one of the initial sponsors, to remove its advertisement.

“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.