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

  • Home / Search engine / StandardJS Pauses Experiment…

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 hear you loud and clear. We’ve reconsidered and have removed the ad.

— Linode (@linode) August 25, 2019

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