Indie Open-Source Sustainability

I was recently recently interviewed by Armin from ThanksDev as their team tackles indie open-source sustainability. Armin really believes in having more developers speaking out about their experiences; something I was tremendously skeptical of, however after hearing segments from his other interviews, and chatting with Armin, I can now see value in it. Below is my preparation for his questions, where I expound more deeply on the themes.

Your name & project introduction

Benjamin Lupton, however you’ve probably used my software under the Bevry moniker instead, among others. I’ve been writing software for the commons since 2005, with now hundreds of npm packages that get 500 million installs a month, that’s 10x more installs than react gets which is by a well funded team.

Motivation behind the OSS project?

It has always been to scratch my own itch, with solutions that rethink and thus simplify the problem space.

In 2005, I set myself up with a teenage blog and wanted to customise it, this saw the creation of various plugins for PrototypeJS (such as Lightbox), for jQuery (such as jQuery Lightbox), and for b2evolution. Eventually I started getting commissioned to build plugins for other people, to scratch their issues too.

In 2010, having watched Google continue to fail miserably to properly implement client-side state management with their hashbang implementation, I leveraged my prior expertise from creating jQuery History and jQuery Ajaxy, to innovate History.js, which solved the problem properly and became one of the top javascript projects in a week.

In 2013, I saw a gap in the technological market again and implemented one of the first notable Node.js projects, a dynamic static site generator called DocPad; its ideas are now seen in tools like Remix and Astro. To make DocPad possible, I first had to lay the groundwork and invent alongside it hundreds of low-level dependencies to empower the higher-level use cases. Even after DocPad’s demise; many of those dependencies have gone on to be foundational to the Node.js ecosystem, enabling the high-level use cases that enterprise depends upon, and enabling the direct dependencies of today that get the eyeballs and sponsorships.

Since then, I’ve been significantly constrained with my open-source portfolio due to a lack of funding; so despite grandiose zero-to-one ideas, my contributions have focused on automating maintenance and easing the maintenance burden.

Number of contributors across all your projects

Open-source projects can take many forms over their lifecycles depending on the intent of the project.

For most libraries, you’ll have a core maintainer, and then contributions are limited to minor fixes and improvements (this is about 99% of my repos — with perhaps 0–5 contributors per repo).

Some projects are intended to be an ecosystem, such as DocPad, where there is an expertise barrier to the core, so that has been mostly me, but alongside a rich plugin ecosystem with a lower barrier of entry. This project reached dozens of active plugin developers and about 150 contributors across its ecosystem from memory.

Some projects are intended to be collaborative, such as the Definitive Listing of Static Site Generators or the Definitive Listings of Text or Binary Extensions, in which a core maintainer lays the groundwork, but the majority of commits are subsequent pull requests; with core maintenance focusing on compatibility with ecosystem conventions and changes.

Some projects grow beyond their original intention, in which their core maintainer will be a merry go round while different companies have different requirements, such as History.js and the typical Browserify maintenance system.

All in all, there’s at least 200 contributors over my several github organisations; however 99% of it has been me, and the automations I’ve written. Which is quite different to some other github models where it is under a brand that initiates it, receives the funding, but outsources all the work to others; which results in high throughput but varying conventions and quality.

What projects are you working on today?

Since 2018, my focus had switched to end user applications, however they are beyond my means to implement in a way that can withstand plagiarism from more well funded entities (the late mover advantage), so they have been shelved. Instead I’ve focused on Dorothy, a dotfile ecosystem that anyone who has ever opened a terminal can benefit from, and most recently Fareness to address the aforementioned competitive issue; it will attempt to give open-source developers a competitive chance against secret keepers who have an extended competitive playbook, which in game theory will always win, unless regulated with (dis)incentives; which is what Fareness will do, it’ll enforce reciprocity either via source or funds, so indie open-source devs can have a fighting chance against plagiarism cohorts, late movers, and extend and extinguish strategies.

Is this a full time gig for you or do you do other work on the side?

The demands are definitely full time, in fact they are more than even I can handle. In all the 17 years I’ve done this, my open-source work has only brought in about $100,000 dollars, which is a wage gap at least an order of magnitude smaller than the equivalent work in a closed-source environment. This is why the indie open-source developer is underrepresented, it is an endangered species, outcompeted by the security, safety, and perks of salaried employees whose open-source efforts are loss-leaders to closed-source returns. To really drill this home, History.js was one of the top 5 javascript projects during its time; used in everything and by everyone; it demanded a full time workload (at one point I had thousands of github issues across my repos to work through); yet it received zero dollars of funding and support. I use to feel as a failure, and have incredible shame that I couldn’t support my work in the way it needed, and eventually the project starved to death from unavoidable neglect; this was at the time when a zero-commit streak on github would shame you with “current status: a rock in a hard place”; I wrote an open issue to github, requesting better support to their top users, which was cosupported by many other devs in the same situation, however it went ignored; salaried employees just couldn’t seem to understand this “slavery to servitude” experience that top indie open-source devs were having. Eventually, most of them would take a hint and drop out and leave, and their abandoned original works would go on to be replaced by plagiarism cohorts under consistent brands.

How much do you need to make this a full time gig?

Just $500/month would allow many of us indie devs to keep our heads above water and stop incurring further debt. However, ultimately, the goal shouldn’t be sustainable asceticism, but ‘like for like’ salaries; we see that the work is important, and abandoning and fragmenting it is damaging, but due to simple economics, scarce resources aren’t traded for free resources, so there is no imperative for ‘like for like’ pay; as such, I believe solutions like Fareness that enforce reciprocity are the only solution for widespread fairness, and not just the sponsored celebrity endorsement model we have today.

What does this money mean to you & what it will enable for your project?

For developers, it will enable the same opportunities that salaries offer employees: A reduction of debt, building of savings, freedom by vehicle ownership, safety by house ownership, security by healthcare, the opportunity to have and support your family.

For projects, it’ll afford the time to maintain them; this means:

• improved productivity for your own developers as maintainers can afford the time to keep their packages up to date with the latest conventions, which also reduces lost time to fragmentation across the ecosystem
• reduced risk as maintainers can afford the time to keep their own dependencies dependencies up to date and patch disclosures reactively and proactively — and unfortunate events are prevented or able to be responded to quickly
• most importantly; maintainers are smart and innovative people, which is why developers elected to use their packages time again, and by funding them, they can afford to contribute new innovations to the commons, enabling companies to better compete with each other.

How does it make you feel knowing that company x is using your project?

The first several years, it felt magical and important; that I’ve made a difference, made an impact, made that dent in the universe. But as the bills accumulate, and the companies that sell your work within a closed-source product get richer, you start to recognise you were just their free labor, and that is part of their competitive advantage; it gets old fast, and is why startups avoid open-sourcing their IP.

How does it make you feel knowing that company x is sponsoring you & your work?

It really matters, even if it is $1/month, it really matters. Reciprocity is a critical piece of civil technology of sovereignty, and if it fails, monopolisation ensues and empire’s colonisation triumphs. There are pros and cons to both models, so no need to be an ideologue about it — however imbalances when not corrected meet chaos; we are seeing over the years, even in open-source, an increase in rebellion from the sovereignty side as the empire side expands. Moderation to ensure both sides gets a seat at the table, have representation, and are supported, goes far to ensuring the bridge symbioses remains open and that parasitism avoided.

What message do you have to companies that are giving back to the community?

Services that reward breadth, splitting $1000/month to a thousand developers makes a much bigger impact than the three hundredth sponsor to the top ten developers again and again. Keeping a thousand developers afloat, so they aren’t rebelling or dropping out, is much better than another house for the memorable. It only takes about $500/month to keep the ascetic head afloat, yet it takes $17,000/month for a top-end competitive salary; if $17,000 was split, that could keep 34 developers afloat. If say 34 companies each do this split, then that is now $17,000 to each of the top 34 developers, rather than another $578,000 to the top dev. There are certainly advantages of the celebrity sponsorship model, the same advantages behind the adpocalypse, however it goes back to the empire vs sovereignty issue. Having a thousand, or even a million companies, sponsoring the top thousand or million indie developers, would go far for protecting sovereignty against empire, and allows everyone a fighting chance, not just the monopolies.

What message do you have for companies that are considering donating?

Even $1/month makes all the difference. It isn’t just you, it is a very ghandi-esque ‘be the change you want to see’; it scales not just the impacts of your behaviour, but it also scales your behaviour to others too! There is a human bias towards following, to not risk standing out; but if a few do, people are generally supportive and welcoming, and you become a beacon. When you donate, you aren’t just donating, but you are spreading the idea of donating, you offer your actions and the ideas behind your actions, a fighting chance.

Generally speaking, what do you believe the factors are in the open-source funding issue?

Normativeness

Any initiative, be it singular or collective, has a telos (a set of values and goals) that manifests and constraints its ethos (behaviors, culture); the more ethos supported by a telos, the wider the normativeness; the more rigid the ethos must be, the narrower the normativeness.

A company that has a wider normativeness can hire more employees, with a more diverse culture. A company that has narrow normativeness can hire less employees, as its culture is more superficial. Companies can also have a narrow normativeness for their internal culture, and a wide normativeness for their external culture.

Companies sponsoring individual developers directly are exposing themselves to this normative risk — it signals support of the developer — does the developer comply with our internal normativeness, our external normativeness, or neither?

Having companies sponsor intermediaries such as ThanksDev and Fareness, allows the intermediary to diffuse this normative risk instead of the company. In the same way we are against sweatshops, but still buy devices and products that used them, because for most of us, that is the manufcaturers problem not ours. Intermediaries allow us to partake in the value, while allocating the risk and resolution to the responsible parties.

Awareness

The biggest issue with current funding paradigms (direct sponsorship) is that they reward only those who funders are aware of — this is either monopolies already, or developers of direct dependencies — yet most of our dependency trees are indirect dependencies.

The realm of indirect dependencies is comprised of hundreds of prolific developers, and plenty more smaller developers. Optimizing for breadth in direct sponsorship will help this: having thousands of companies giving equal money to thousands of developers, or at least a hundred developers, instead of just five or ten. However, the solution is that which a single payment goes to potentially millions of developers.

The ecosystem needs to do a better job of raising awareness for the need to fund a larger breadth of developers so they can keep their heads above water, so such developers are found and supported, or to promote solutions where a single payment is split between a plethora of developers.

The other issue here, is that many prolific devs will choose to collaborate under a github organisation that is a moniker — not a personal brand — and as such, there is the false assumption it is a well-funded company that doesn’t need funding as it has high throughput — yet it is just some committed indie devs.

Scarcity

While sponsorship is the dominant way of funding indie developers, it isn’t the dominant form of funding open-source, which is open-core, or rather giving a portion of your source code away, yet increasingly moving the key value into closed-source offerings. This is not good for the commons and it is not good for companies’ abilities to compete with each other. It moves the open-source landscape from indie developers to big companies that can extend and extinguish competition better.

Enforcement

What open-core has recognised, is that the scarce resource of money isn’t traded for the non-scarce resource of open-source code; there has to be a scarce for scarce trade at play. This can either be in the form of advertisements of sponsors (this is optional so is not enforced), the form of open-core (scarce extensions, this is partial so is only partially-enforced), or in the form of dual-licensing (open-source but charges for commercial use, this has been lacking the ability to enforce). Developers are now looking to solutions like Fareness to allow enforcement of dual-licensing.

Black Sheep

Prolific developers may decide to leave the industry if their efforts are not reciprocated. This has taken many forms, some silent, some vocal, some rebellious. What they all have in common is a feeling that they are black sheep, that their work is consumed yet they are not rewarded, that the industry is not rejecting their work but it is rejecting them. This exodus of top talent from open-source is awful and hurts everyone. Companies should take pride when funding the breadth of open-source, ensuring the developers of the commons that their products are built upon are also valued, and not just their employees.

Let me know your thoughts, which you can also do so privately by emailing me at b@lupton.cc — happy to chat.

If you wish to fund once and have it distributed to many developers of the commons, then these services are live today: ThanksDev, StackAid, TideLift

If you are inclined to support me directly, you can do so via GitHub Sponsors.

And if you despise everything about this, then please consider funding a service-dog for Helen instead.