The Open Source Pledge Blog

npmx: A Lesson in Open Source's Collaboration Feedback Loops

Vlad-Stefan Harbuz — Tue, 03 Mar 2026 06:00:00 GMT

npmx launched today, and witnessing its incredible development journey has taught me a lot about what I’m calling the collaboration feedback loops of successful Open Source projects — patterns where every contribution to a project makes future contributions easier, creating a virtuous cycle of collaboration, enabled by trust and collective governance. Let’s start with some details about npmx.

JavaScript is one of the world’s most popular programming languages, and JavaScript developers use the Node package manager (npm) to incorporate packages written by others into their work. npm packages can be accessed through npmjs.com, but this website, maintained by Microsoft’s GitHub, has not been gaining new features at the fastest pace. Currently, its entire homepage is an ad for paid services offered by Microsoft.

npmx is a brand new browser for npm packages, developed by the community. It doesn’t replace the npm package registry, it just offers another way to browse the packages in it.

On 22 Jan 2026, Daniel Roe made the first commit to npmx, and 10 days later, 100 people had already contributed to it. 13 days in, the numbers were even more impressive: 199 contributors, with over 1000 merged pull requests.

Of course, npmx has plenty of innovative features, some of which I’ve never seen in another package manager interface: package comparisons, community flagging of vulnerabilities and outdated dependencies, automatic documentation generation, and detailed download charts.

npmx even runs its own atproto PDS, which is a great home for the social accounts of Open Source projects, since it provides them with a community-run, European-hosted home. That’s where the Open Source Pledge Bluesky account lives now.

But what I find most impressive about npmx is something else: how its team has fostered a culture of trust and playfulness that has enabled the speed and scale of its development by creating collaboration feedback loops.

Collaboration Feedback Loops

Here’s where the feedback loops come in. At least two things are required for a project like npmx to come into being.

First, imagination. We’re so used to the practices that are common in our everyday lives that it can be difficult to get into the mindset of imagining alternatives. But imagination is an activity best done socially. Once Daniel raised the possibility of alternatives to npmjs.com, and once the community started bouncing ideas around, hundreds of contributors came up with suggestions they would not have come up with individually. Each contributor built a foundation for the next person’s imagination.

Second, implementation. There’s a lot of work to do on a project like this, and not everyone has the time or expertise to lay down the technical foundations. But the more npmx developed, the wider the variety of work available became, giving would-be contributors an ever-increasing range of tasks to test their skills on.

This is the collaboration feedback loop of Open Source. Earlier contributors make future contributions easier, both in terms of imagination and implementation. Each contribution sends ripples beyond the code contained within it — present contributions set up a ladder for future contributors to use.

But there are at least two conditions that must be met for this virtuous cycle to happen.

Open Collaboration

The first condition is open collaboration. It’s obvious that there’s a kind of collaboration feedback loop when any two people collaborate, like when you and your partner bounce ideas off each other. Loops of larger scales can happen within companies — one on the larger side might have 50 or 100 developers.

But only global, fully open collaboration can produce virtuous cycles on the scale that Open Source has given us. Open collaboration gives us a huge potential base of contributors, with a variety of ability that is impossible to find within any single company (Weber 2005, ch 6).

This global base of contributors is what npmx is leveraging, and ironically, Microsoft itself has admitted that “commercial quality can be achieved/exceeded by OSS projects” (Weber 2005, p 126).

Trust

The second condition is one that npmx meets with flying colours: having a culture of trust. 5 weeks into the project, npmx already has 18 maintainers. Many creators would struggle to find the trust to give 17 people a say in the governance of a project they just started. But the esteem implicit in trust motivates people to do their best and to build relationships with those that took a risk for them.

This kind of trust reveals a deep understanding present in npmx’s culture — an understanding that we depend on other people more than we know, and that we can only go so far by ourselves.

In npmx’s case, this distributed governance model has paid off, and not just in terms of productivity. The sheer energy, optimism, excitement and hope in the npmx community is something I’ve rarely, if ever, seen in an Open Source project. It feels like the opposite of corporate drudgery; like a big programming sleepover where everyone is excited to playfully create.

Of course, no collaboration feedback loop can increase in speed forever, and npmx’s growth will eventually settle into a cosy steady state. But how nice it is to witness this cultural moment in Open Source. And how nice it is to be part of it! I have made my own first contributions to npmx.

In a different sense, the npmjs.com team is also participating in the fun — it looks like the success of npmx has pushed them to ship their first new features in a while.

But companies that depend on npm can participate, too. That’s most companies, by the way.

Many companies are already supporting the Open Source maintainers whose work they depend on, by paying those maintainers and becoming members of the Open Source Pledge, which is how we’ve raised $6,904,318 for Open Source maintainers to date.

Supporting npmx financially certainly counts towards Pledge membership. But more than that, it’s a way for companies to support not only the technological innovators they rely on, but also the cultural innovators: those who enable Open Source innovation with their vision of trust and collective governance. Our global tech ecosystem wouldn’t be there without them.

Support projects like npmx now

Join the Pledge

Welcoming the Open Source Endowment

Chad Whitacre — Thu, 26 Feb 2026 17:00:00 GMT

Congratulations to the Open Source Endowment (OSE) on their public launch.

OSE brings the endowment model to bear on the problem of Open Source sustainability. What is the endowment model? It’s the main way universities and other cultural institutions fund their work. For example, Harvard has amassed an endowment of $57 billion over the centuries, and they fund their year-to-year activities from the interest (taking operational costs and inflation into account, of course). Endowments are a well-trodden path. It’s high time to bring the model to Open Source.

How does the Endowment relate to the Pledge? They are complementary. Pledge companies directly pay maintainers. Endowment members are generally individuals investing broadly in the long-term future of the Open Source ecosystem. It’s like alumni from a university giving back—where successful software engineers, and especially technical founders of successful companies, are the alums.

Full disclosure: I am on the founding board of OSE, and Open Source Pledge maintainer Vlad-Stefan Harbuz is an advisor for OSE.

New Models to Address Mounting Pressures

Open Source–adjacent business models continue to face mounting pressure. First it was companies like Amazon undercutting projects like CockroachDB and Elasticsearch. Today, AI provides an even bigger threat, as highlighted in a recent paper, “Vibe Coding Kills Open Source.” There are of course ways in which vibe coding fuels Open Source. That said, AI does insulate developers from the OSS projects they depend on, removing a key channel for business models that subsidize project maintainers.

As it was going to press in January, the paper’s key result proved true. Tailwind's Adam Wathan revealed that traffic to Tailwind's docs website went down by 40%, because people were consulting documentation through LLMs. This meant that potential customers weren't seeing Tailwind's paid offerings, bringing revenues down, and causing them to fire 75% of their engineers.

The vibe coding paper concludes: “The solution is to redesign the business models and institutions that channel value back to OSS maintainers.” Both Pledge and Endowment are doing just that.

Pledge companies have contributed almost $7m to maintainers since our launch. That’s real progress. We look forward to seeing how much further the Open Source Endowment can take us as an industry, and especially how the community will shape its funding allocation model. We encourage all of you software developers to contribute to OSE in proportion to the success that OSS has brought to your career.

You Have No Excuse for Tailwind

Chad Whitacre — Thu, 08 Jan 2026 13:45:00 GMT

Open Source economics are broken, and AI is rapidly accelerating the crisis. Adam Wathan and his team built one of the most popular Open Source projects on the planet, Tailwind CSS, and their business model around it disappeared overnight because of AI.

“[I feel] like a fucking idiot for somehow being able to build this CSS framework that’s taken over the world and is used by everything and is super popular but I can’t figure out how to have it make enough money [for a small team to work on it].” — Adam Wathan

That ain’t right.

Current and former member companies of the Open Source Pledge have been systematically doing our part to pay for the value we receive from Open Source volunteers, including Adam and his team. It’s time for the rest of you to step up.

Join the Pledge. Pay for the value you receive from Open Source maintainers like Adam. You have no excuse.

Burnout in Open Source: A Structural Problem We Can Fix Together

Miranda Heath — Tue, 18 Nov 2025 08:00:21 GMT

Imagine this: you build something to address a need that you have. It works — and it works well! Realising it might be useful to others, you decide to share it as Open Source.

To your surprise, it quickly becomes popular. Your work is valuable to others. It feels like a dream!

Then the requests for features and fixes come pouring in. Some feel more like demands. You care deeply about what you have made, so you try your best to respond.

You do this in your free time, but it starts to feel like a second job. Your working days get longer and longer — some nights you barely sleep. You know your work is valuable; massive companies are using it under the hood! It’s a rare day when anyone stops to say thanks for the hours you put in — but for them to offer any sort of financial support? Almost never.

A pull request comes in. Someone earnestly trying to help? Nope — it’s clearly something they threw AI at without understanding the code.

It carries on like this for months. The project you made for you, once a source of joy, is now a source of stress and anxiety. You feel profoundly unseen. Reluctantly, you begin to wonder: is it time to give up on the dream?

I’m a psychologist, and I’ve been compiling a report on the problem of burnout in Open Source Software (OSS).

Over the past 5 months I have interviewed OSS developers, read dozens of academic articles, and analysed 50 pieces written by members of the OSS community to try to identify the causes, and possible solutions, to OSS developer burnout.

I have been struck to learn how much the software infrastructure we rely on every day is made possible by developers choosing to make their projects available Open Source, with over 96% of all companies depending on Open Source software. Even more striking, I discovered that choosing to make and maintain software as Open Source is putting developers at risk of the very real psychological harm of burnout.

Burnout is an exhaustion of physical and mental energy, typically associated with work. Burnout leaves us feeling drained, that we have no fuel left in the tank, that we are running on fumes. When we are burnt out, it is hard to motivate ourselves, to control our emotions, or to think positively about our work.

It is a huge predictor of quitting.

The risk of burnout increases when there is an imbalance between the energy our work demands of us, and the resources available to replenish it. For example, if we are expected to work long hours under higher pressure, yet the work is unrewarding, we aren’t supported by our colleagues, and we are not fairly paid or recognised for our efforts, there is a good chance we will end up burning out.

Unfortunately, conditions such as these are common in OSS, 73% of software developers around the world experience burnout at some point in their careers, and more and more (and more!) often, conversations about Open Source sustainability are turning to the topic of burnout.

The consequences of developer burnout are system-wide. When the team — or, shockingly often, single person — maintaining a project is running on fumes, exploits get missed and malicious collaborators go undetected, putting the security of a frightening proportion of our global software infrastructure at risk.

Clearly, burnout in OSS is a critical issue in need of an urgent solution. I want to tell you about two issues my research has identified that are pushing developers to the brink:

Developers are struggling to make a living
Toxic behavior from community members is wearing developers down.

Dissecting these issues, we will see that burnout in Open Source is not an individual problem — it’s a structural one. Hotfixes like teaching maintainers to be more resilient can only get us so far: it may be time for a substantial rewrite of some of our Open Source practices.

1. Developers are struggling to make a living

Very few developers are able to sustain themselves financially through OSS alone, and many feel despondent about the very possibility of reliable payment for OSS.

A common theme in OSS community discussion was that of the ‘double-shift’. Many developers have full-time jobs outside of OSS in order to pay the bills. While OSS might start out as a hobby, once a project takes off, maintaining it takes multiple hours of work each day. Doing both a full-time paid job and a second ‘stealth job’ in OSS, developers face intense workloads, long hours, little sleep, and difficulty finding time for friends and family. This is unsustainable, and erodes their physical and mental health.

To add insult to injury, OSS developers often feel exploited by the beneficiaries of their work. Their code and the effort they put in to maintain it enables the software industry to be enormously profitable, and yet it is an uphill struggle to receive anything in return, leaving many feeling they are doing ‘free labour’ for software companies that have the resources to pay them and a market that is failing to recognise their contributions.

Psychological research shows that high demand, low reward and feelings of unfairness in work are all associated with an increased risk of burnout, and many OSS developer testimonials highlighted the amount of time and effort they were putting into their OSS, only to receive little-to-nothing in recognition of their efforts, as instrumental in causing their burnout.

‘There was a long time where I was doing Open Source almost more time than my full time job, and getting paid nothing. I just burnt out. I stopped writing and contributing to Open Source.’ – Marc Grabanski, Open Collective Case Studies

If it were easier for OSS developers to get regular, reliable and sufficient compensation for their OSS work, they wouldn’t need to rely on additional full-time employment to pay their way while contributing to OSS. They would be less likely to feel like they are being treated unfairly by the people that benefit from their labour. They would have more time to do the things that replenish our energy: full nights of sleep, full days with the people we love. This would greatly reduce the risk of burnout.

However, while payment for OSS is an important part of the solution to the problem of OSS developer burnout, working out how best to implement it in practice is a real challenge.

Some developers fear the wrong model of payment could pressure them to act in the best interests of their funders, rather than their own interests or the interests of the community. This could in fact make burnout in OSS worse; psychological research suggests the risk of burnout is higher when we lack autonomy at work.

This fear is also not unfounded: the recent Ruby Gems takeover fiasco highlights how the pressure to appease sources of funding can change the direction of an Open Source project, resulting in maintainers losing control over a project they stewarded for many years.

It will take hard work and productive community discussion to figure out the details. Perhaps we need decentralised funding, such that no project is reliant on a single source of income. Maybe funded OSS projects need collective governance, to protect maintainers from the whims of the fabled BDFL. Whatever precise shape it takes, the model of payment for OSS that is most protective against burnout will be one that allows maintainers to make a living while maintaining creative control over their work.

2. Toxic behavior from community members is wearing developers down

It is more than just a lack of financial compensation that is making OSS developers feel exploited. In both the academic literature and OSS developer testimonials, one issue kept coming up time and time again; a vocal part of the userbase can be entitled, insulting, and downright toxic.

Psychological research tells us that hostile communication and pressure to be polite to antagonistic people increase the risk of burnout, and developers are struggling in the face of intense criticism and unreasonable demands for features and fixes.

It is not straightforward for developers to say no to unreasonable requests either. Open Source developers are strikingly conscientious. Many feel responsible towards the people that depend on their project and feel guilty for leaving requests unanswered. Coding is their craft, and it takes strength to separate comments about the quality of their code from their sense of worth and identity as a craftsman.

Combine this with the fact that, once a project is popular, responding to requests and reviewing code can take hours and hours every single day, and it is easy to see why many developers feel that maintenance work can be truly thankless.

‘[T]he angry response has been overwhelming. Every single day I'm reading someone else rant about how awful of a job we're doing. It's been hard to stay motivated - James Kyle, Dear JavaScript

Normally, when we receive something for free that is beneficial to us, we react with gratitude. However, it seems as if a portion of the Open Source userbase are acting as if OSS were a service provided by a company. This is the typical model of consumption in a market economy. But Open Source has always been different. Open Source is a common resource pool — people contribute for free, and the more people contribute, the more it benefits all of us.

If it were possible to shake users out of their default mode of consumption, to realise that Open Source is a gift not a service, provided by a small team or even single maintainer in their free time, they might be less inclined to be hostile and demanding. This would make maintenance work less thankless, and less likely to lead to burnout.

Changing group attitudes is hard. A good place to start could be with GitHub, who are well-positioned to educate users about the nature of Open Source. Leaders in the OSS community could also help raise awareness; psychological research tells us community leaders are particularly effective at shaping group practices.

While it is clear that toxic communities can break maintainers down, positive communities, where our interactions with others leave us feeling supported and give us a sense of belonging, are associated with a lower risk of burnout.

One way this could be achieved is by organising community-focused events. These serve as watering holes at which the OSS community can gather, support each other, talk about their feelings and frustrations, and find paths forward together. Unfortunately, community events are currently few and far between and can be expensive to attend.

Another way this could be achieved is by increasing access to resources like mentoring relationships, coaching, mental health support and communications training, so developers feel supported and better able to cope in the face of demanding users. But it is hard to know how to implement this in Open Source: who would offer it, and who would pay for it?

Perhaps companies that rely on Open Source and recognise the need to give thanks to the OSS community could sponsor community events that aim to build social and emotional support among maintainers, or advance principles of good governance. Alternatively, they could fund, organise or offer access to coaching and training resources that enable developers to feel socially supported, while they support the software infrastructure we rely on every day.

At its core, burnout is an utter depletion of motivational energy. It is a state of exhaustion, an inability to conjure any further effort, and it is brought about when our work takes more energy from us than it gives us in return.

Developers who manage to avoid burnout find ways to give in line with what they get. They don’t spend time responding to people who don’t provide minimal reproducible examples. They put as much effort into reviewing code as the author put into writing it. They learn, through great personal strength, to say no, even though they care deeply about the quality of their work.

But there is another way to rebalance the energy equation. What if instead of leaving developers to learn to refuse or burn out trying, we give something back? A move towards a community in which OSS developers are recognised as worthy of gratitude for the hugely beneficial work that they do, in which they have social support, are treated with respect, and enabled to afford to live comfortably, is a move towards a community without OSS burnout. It is time to recognise the humans behind Open Source.

You can read my finished report in full using the button above. I am really keen to get feedback from the Open Source community to ensure I am fairly representing their views. If you work in open source and can spare some of your precious time to read the report, I would love to hear from you! You can talk to me on Bluesky @mirandaheath.website, Mastodon @[email protected] or drop me an email at [email protected].

Illustrations by Harriet Boeing. Additional work by Vlad-Stefan Harbuz, Greg Kumparak and Michael Selvidge.

A GitHub Co-founder's Next Commit

Greg Kumparak — Wed, 10 Sep 2025 16:58:00 GMT

GitButler is a member of the Open Source Pledge, where companies commit to contributing at least $2,000 per year for each developer on their team to open source maintainers. Before GitButler, founder Scott Chacon co-founded GitHub; for this profile, I talked with Scott about how he 'fell in love' with Open Source, the legacy of GitHub, how AI is changing development, and what he's building today and why. Enjoy!

In talking with Scott Chacon, I realize he has a superpower: he really likes to understand why things work the way they do, and to make sure others do too.

"My first job was working at this trade show registration company,” he tells me “They were using all of these FoxPro scripts, and everything seemed so slow. Every script was just iterating over every single row.”

"I opened up the manual and found that you could just use SQL to do everything like 100x faster.” he continues. “My bosses didn't think my scripts worked at first, or that I'd written them. They were too fast."

The lesson stuck: sometimes a better solution is right there waiting. You just have to take the time to dig.

"All of those systems ran on Linux. It got me into compiling my own kernels, and looking at source code because you could mess around with everything. When there was a problem, you'd ask friends or go on the Internet and you could figure out how to fix it."

"Even through college I ran on a Linux desktop. I wanted to be ‘that guy’," he says with a knowing laugh. "I wrote all of my papers in LaTeX instead of Word. Was it harder to write my papers, format them, and actually get them printed? Yeah. But at least vim doesn't crash."

"That's where I fell in love with Open Source,” says Scott. “I got involved with PHP, I wrote some stuff, tried to share it. Eventually I moved into Ruby on Rails… and Open Source was everywhere."

"By the time I met [fellow GitHub co-founders] Chris and PJ at a local Ruby meetup, I was already kind of known as the 'Git' guy, because I was always doing stuff with Git." he tells me. "But the Git stuff is funny because… well, I actually found it really difficult at first. A friend of mine was teaching it to me, drilling it into my head, and I finally got it. I was like: wait, you know what? This is super cool."

"So I started writing. I wrote a book called Pro Git — which is still selling well, two editions and f*#&ing fourteen years later. It's fun to teach, and it's fun to write, and to make something hard into something easy. If you can help people have that epiphany about something, and they start to love it… it’s incredibly satisfying"

"I'm actually not that good at Git!" — a funny line from someone who wrote the book on it, but he continues. "I just understand what it's like to not understand something, and what it's like to get over that. I have a drive to understand how it works at a fundamental level so I can teach people."

The GitHub Effect

While GitHub itself is not Open Source, the massive impact that GitHub has made on the Open Source world — and on software development overall — is inarguable. It’s ubiquitous enough that dropping your GitHub profile in a software engineer job application is more the rule than the exception.

As Scott put it in a 2023 interview: "It’s almost impossible for most of us to remember what Open Source was like before GitHub."

I ask Scott when GitHub's importance dawned on him.

"I was prepping a talk where I was giving people the history on what it was like before,” he tells me. “I was pulling out examples, like manually attaching patches to Redmine issues, or shipping tarballs and sh*t in the Linux community. The processes were… really not good. "

"You'd start a new dev job and onboarding was like 'Here's how we do version control, here's how we do this and that. Blah blah blah.’” he says. “Now it's all GitHub, or a clone of GitHub. Git provided the tool set for GitHub to make all of it much better."

Scott Chacon giving a talk on Git in 2014. Photo by Andrés Moreira, shared under a CC BY-SA 2.0 license; the photo has been cropped.

Even 16 years after its founding, Scott thinks about the ways GitHub influenced the way people build and how the way they build is changing right now.

"When we put the 'Merge' button on the website, there was a shift. Review and integration shifted off [your local machine]. All review and integration was done locally before, right? You would pull in a branch, you'd look at it, you'd merge it locally, then you'd push it back up. The whole process was more… artisanal, I guess I’d call it.”

"Now a lot of people are integrating code that they’ve never run locally. Maybe someone wrote it locally, but the reviewer? It's too cumbersome to pull down; when it was all patch-based, you had to! There was just no way to do it otherwise. We pushed that away in the name of ease of use, so now it's easy to be like 'Whatever, looks good to me."

"I kind of like this idea of having everybody be a little closer to the code."

On AI

"With AI, vibe coding, coding agents… it's getting even further away." Scott notes. "Review is more important than ever and yet it's as weak as it's ever been, right? You see 37 files and 1500 lines changed, and you're like… you know what? I'm not going to go through that."

But if there’s one camp that’s ready to embrace AI coding tools and another that’s staunchly against it, Scott is very much in the first one — and he sees more holdouts coming around every day.

"Even in my circles, I've seen people who were like 'I'd never touch AI with a ten-foot pole! It's horrible!' now doing large refactors with it, and being like 'Eh, I was wrong.’” he says. “Everybody is learning what it's good at, what it helps with, what it doesn't help with, and where you get stuck in the loops.

“It's a slow thing,” Scott tells me. “but I think in the future it'll feel insane to not use AI for at least some of your workflow."

"That means changes to everybody's workflow,” he notes, “which means there's opportunity for some other GitHub-type thing to come in and make that workflow easier."

"Look at anything on GitHub,” he continues, “and think of it from the point of view of: is this good for teams of humans, each with agents (and agents that work by themselves in the cloud), all working on one code base? Is this the right tool set for that team? I think the answer to that is fairly clearly 'no'.”

On What's Next For Him: GitButler

Scott stepped away from GitHub in 2016, just prior to it getting acquired by Microsoft in 2018 for $7.5 billion in stock.

After that sort of exit and the windfall that comes with it, it'd be easy to disappear into some hobby you love — like, say, woodworking. Which is exactly what Scott did… for a while.

"I just really missed the startup world," he says.

His first post-GitHub company was a language learning startup called Chatterbug. It didn't work out, but he's still very glad he did it. "I came out of it learning German, moving to Berlin, and marrying a German woman. So, yeah, worth it."

His next swing? GitButler — the git client of his dreams, and, ideally, one that evolves with the way he foresees development changing.

"I look at Git, and it's somehow still this thing that people don't care about that much. Who are the GitHub competitors that are interesting today, or in the last eight years? Like nobody!"

"I can go through every GitHub page and point out seven things that frustrate me, or that should be better by now. Or you can go to GitHub Next, which is [where GitHub shares prototypes and research]... why are none of these things startups?

"I think it's because nobody finds version control 'sexy'...” he tells me. “They say 'Git? Whatever, solved problem!'”

"But there's 1000 things that are really frustrating about Git! Even I get frustrated by Git sometimes."

With GitButler, his goal isn't to replace Git — but to fix what frustrates him about it from the client side.

"I wanted a client with taste, that was actually good at what it did, and was delightful to use. I wanted a Git client, but I didn't want it to act like Git. I want it to write git objects, and write git trees, and use the protocol… but where you don't even really need to know that you're using git."

"I thought it was an interesting challenge: what if GitHub had made the client from scratch, and owned it, and could deploy features to the client… what might that have looked like?"

From there, the goal is to get ahead of where Scott sees development going with AI.

"You can see how little people give a sh*t about version control by how most of the AI companies deal with it, which is to say: they don't."

"Half the time you'll do seven prompts, change all this code, push the code, and say 'Ok! I think I've fixed it.' You've just lost everything. There's no prompt information, no context, there's nothing."

"If AI agents are generating all this stuff, we need to have save points, and for it to be so easy to revert… We need the prompt information in the commit. When an agent is working on something, we need to be able to say: why was this written? Not what was written — that's easy. But what was it trying to do?”

Scott has spent his career finding better ways to build — from those early FoxPro scripts to version control to whatever comes next. Now three decades in, as he watches AI change how the world writes code, he’s focused on making sure we don't lose something he’s cared about since day one: an understanding of why.

Buttondown: How One Team Built a Successful Business by Building Less

Greg Kumparak — Tue, 15 Jul 2025 16:55:18 GMT

Buttondown is a member of the Open Source Pledge, where companies commit to contributing at least $2,000 per year for each developer on their team to open source maintainers. In this member spotlight we’ll look at who Buttondown is, what they do, and why they joined the Pledge.

When Justin Duke started building Buttondown, he didn’t really mean to start a company. He wasn’t trying to raise a bunch of money. He wasn’t chasing unicorns.

He just wanted a newsletter tool that didn’t feel broken.

“I was using this tool called TinyLetter,” he tells me. “I loved it. But they got bought in 2011; years later, it had just accumulated cobwebs. You could tell it hadn’t been touched in literal years. There were very, very obvious bugs.”

At the time, Justin was living in Seattle, sending a newsletter to a small set of family and friends to keep them in the loop about his life.

“I had used TinyLetter for years,” he explains. “And, well, finally I got to the point where I had the very terrible idea of building my own version of it.”

By day, he was working full-time as an engineer at Stripe. On nights and weekends, he was hammering away at this tool originally just meant to scratch an itch. Then, as things tend to go when you build something you need, others saw it and wanted it too.

“It was just meant to be this self-hosted thing.” says Justin. “But I would show people and they’d say ‘I’d use this! How much does it cost?’

“That… wasn’t really what I wanted to do.” he notes. “But it got to a point where I was like: ok, i’ll add a user table to the database. I’ll push out a janky MVP and iterate from there.”

“I’ll stop running it off my own laptop,” he laughs.

That was 2017. Fast forward to today, and Buttondown is a lean and still highly-focused platform powering newsletters for thousands of customers. The tool that inspired its existence has shuttered. The team has grown to a half-dozen-or-so full time employees, but they still haven’t raised venture capital – and not for lack of outside interest. It’s just not the way Justin wants to build his company.

A Different Kind of Company

“I owe my livelihood and career to the tech industry,” Justin tells me. “But if there’s one complaint I have about it, it’s that it’s fallen into a kind or feast-or-famine mindset, where you have this one possible correct end game: it’s an IPO/billion dollar exit, or it’s failure.”

"At first I just wanted to be able to sustainably draw a salary. Once I did that, I wanted to be able to hire people to do the work that I’m ill-equipped to do or don’t like doing. Then the goal was just being able to offer health insurance, and we hit that.”

“By being laser focused on what we do, we get to be one more data point that like… this is how a tech company can also work. If you build a product that is valuable to users, and those users pay you for that product, that is a very valuable and morally honorable existence. “

“Maybe that’s idealistic or something,” he notes. “But I feel like we’re entering an age where that is becoming more and more possible… and yet, somehow less acknowledged. To be able to run a company where people get to build something in service of something that they care about, and not have to worry about ‘How do we 10x this by this time next year?’… I just feel like more people who are talented engineers, or would-be founders, should consider it.”

A screenshot of the Buttondown interface

Being more by doing less

If you’ve ever used any of the huge name newsletter/marketing tools, you’ve probably gotten lost in the user interface more than once. By trying to be something for everyone, they’ve boiled-the-frog on feature bloat to the point that they’re labyrinths.

By staying focused and lean, Justin says the team is able to build the product they want, instead of what everyone might want.

“We found a lot of success in selling customers on what we don’t have.”

Buttondown doesn’t do everything for you. It’s not supposed to. It’s opinionated. A bit scary, even, to those outside of the audience they’re trying to reach.

“Especially early on we’d deliberately reference Markdown on our landing pages – two or three times, very intentionally, as a sort of shibboleth.” notes Justin. “If you saw this little snippet of Markdown text and you’re terrified or you don’t know what it means: wonderful! Because Buttondown probably isn’t the tool for you. We’re meant to be relatively technical.”

“Don’t want to deal with a janky WYSIWYG editor? Great, write your own Markdown. We’d get customers from these huge platforms…they’d outright say “I’m leaving my old platform because they keep adding stuff I don’t need and charging me for it.”

“We found a lot of success in selling customers on what we don’t have,” he notes.

How Open Source makes it possible

Buttondown was one of the earliest companies to join the Open Source Pledge, committing to contribute at least $2k annually per developer on the Buttondown team.

Justin is very open about why: “None of the stuff that we do would be possible without the Open Source software we use.”

“My biggest competitor is a company with 20,000+ employees. The way we’re able to compete and build high quality software is by sitting atop all of these really, really strong Open Source frameworks, built by people who largely give their time and energy and lost sleep to make these things better. Django, Vue/Vite, and a long, long tail of really great single purpose packages… it’s just an entire universe of problems we don’t have to think about.”

“Prior to Buttondown I spent all of my time at bigger tech companies,” he clarifies. “The thing that I was never able to really square in my head was… all of this success, all of this revenue and growth, it’s downstream of these specific [Open Source] projects. It wasn’t even moral indignation; it was a sense of confusion: why aren’t we paying someone to help them work full time on this? Isn’t that just an obviously reasonable thing to do?”

“As soon as Buttondown was generating revenue, we found a way to make this work well within our margins. Even at the point where it wasn’t paying my salary — when it was just a nights and weekends thing — I would do the math and realize we were giving more to Open Source than many Series C companies with hundreds of employees. Why? It’s just wild.”

What’s next

Stories like Buttondown’s tend to be seen as anomalies — or, at least, they’re not the ones that pull the headlines. A solo founder, building something they need, growing at their own pace, waving away outside funding and any imposed grow-at-all-costs urgency.

Justin didn’t set out to build a company, but he’s ended up building one that generates real revenue, pays it forward, and proves there’s a very valid path in building thoughtful tools made by and for people who care.

And if they don’t take over the world? Justin’s okay with that. In fact, it’s the dream.

“If 10 years from now, 20 years from now, Buttondown is still here — maybe a little bit bigger, but still just a small company, laser focused on what we do… that’s really the happiest I would be.”

Not Paying Open Source Maintainers Is Expensive

Vlad-Stefan Harbuz — Wed, 18 Jun 2025 20:21:42 GMT

Because Open Source software is free, some companies struggle to understand why it would make financial sense to pay for the Open Source software they use. But more and more companies are starting to see that paying the maintainers of the Open Source software they rely on reduces their company's exposure to risk, saving them money in the long run.

This is because paying maintainers helps companies safeguard the stability, security and innovation that keeps their products going. Paying maintainers enables them to help you comply with upcoming cybersecurity legislation. And companies that pay maintainers get a competitive advantage by attracting customers, employees and contributors.

Here's a breakdown of the reasons why you will benefit from paying the maintainers your company depends on, and, in doing so, becoming one of the pioneers of a better Open Source ecosystem.

1. Pay maintainers to avoid stability and security problems

Why does software become unstable and insecure if we don't pay maintainers? Well, if you don't pay for the Open Source software you use, someone else has to bear the cost of developing it. Most often, this cost takes the form of a reduction in living standards for Open Source maintainers, who have to work an unpaid and burnout-inducing second shift after their day job.

This arrangement harms the maintainers that your work relies on. But it harms you too, even if most of the time it's hard to notice. Maintainer burnout means the Open Source software you rely on becomes less stable and secure. Issues with widely-used Open Source software are always being uncovered, be they bugs, accidental security issues such as Log4Shell, or maliciously introduced exploits such as the XZ Utils backdoor.

These two exploits were enabled by [email protected]/msg00567.html">mental-health-harming maintainer burnout, with some maintainers of critical software at times working 22 hour days for free. The only reason these exploits didn't cause a catastrophe affecting hundreds of millions of people is that they were discovered early. But how many more vulnerabilities in industry-wide infrastructure lurk undiscovered? As soon as maintainers burn out, supply chain attacks become easy.

Don't let your business rely on at-risk software — pay the maintainers who can make your stack sustainable and secure. Paying to avoid the liability caused by unstable and insecure software just makes financial sense.

2. Pay maintainers to safeguard the Open Source innovation you rely on

Innovative Open Source projects have enabled us to watch YouTube videos, go to space, exchange medical records and keep in touch with friends and family. Open Source projects have a competitive advantage in innovation, since they have access to a global contributor base of subject matter experts. Microsoft's own managers have remarked that “commercial quality can be achieved / exceeded by OSS projects”. But if only those who make personal sacrifices can be maintainers, maintainership is discouraged, which leads to a decrease in Open Source innovation. If you want your business to be able to continue leveraging innovative Open Source software, the most sustainable way is to pay the maintainers who do the innovating.

3. Pay maintainers to conform to new cybersecurity legislation

The EU's Cyber Resilience Act, which sets out minimum cybersecurity requirements that must be met before software is placed on the EU market, has come into force. By December 2027, companies will have to ensure that both their internally authored software, and the entire Open Source supply chain their software depends on, complies with these regulations.

Auditing all of the Open Source packages you depend on, and all of the packages they depend on, is daunting. The most reliable way to ensure compliance is to collaborate with Open Source software stewards — basically, foundations — that take on the work of certifying certain Open Source packages. But at least 50% of foundations say they have insufficient financial support to actually ensure CRA compliance.

Open Source foundations are your greatest ally in ensuring you comply with EU law, but they can't do this if they don't get paid. That's why your company should pay the Open Source foundations relevant to your ecosystem.

4. Pay maintainers to demonstrate thought leadership

Being a forward-thinking Open Source pioneer that pays maintainers reflects positively on your company's brand, which can persuade customers to choose you over a competitor. Paying maintainers tells customers that you care about the health of your industry, because you're in it for the long haul, instead of focusing on short-term profits. It shows that you're connected to the prominent companies, foundations, maintainers, CEOs and writers that recognise the Open Source sustainability crisis. Most of all, it shows that you are a thought leader that understands their field deeply and anticipates problems before they occur.

To communicate these values to customers, the Open Source Pledge regularly promotes member companies, be it [email protected]">on the Nasdaq tower in Times Square, in outdoor advertising campaigns in San Francisco, or online. Join us by paying maintainers.

Open Source Pledge members being promoted on the Nasdaq tower in Times Square. Join the Pledge by 30 Apr 2025 to be featured in our second round on the Nasdaq screen

5. Pay maintainers to build connections with contributors

Your company probably depends on Open Source contributors in one way or another. Often these are the contributors that add features to the Open Source libraries you depend on, but they could also be contributors that improve Open Source or source-available projects that your company has published.

These contributors are important to your business, because they enable you to leverage not only your employees' skills, but also the skills of a global base of specialised developers, which is a real business advantage. It's in your interest to not only attract contributors, but also to ensure contributors stick around to help.

Though Open Source contributors are not primarily motivated by money, people will be more likely to contribute if they know they will be paid fairly for their work.

6. Pay maintainers to make recruiting easier

Developers are aware of the crisis that Open Source sustainability faces. If developers looking for work know that you take seriously the sustainability of the Open Source ecosystem they work within, they'll be happier working for you than for your competitor. Becoming a member of the Open Source Pledge is a great way to convey your values to prospective employees. Open Source Pledge members are eligible to use our member badges on their website and job board, and also get their job postings listed on the Open Source Pledge job board.

If these arguments make sense to you, use platforms like thanks.dev, Open Collective, GitHub Sponsors and ecosyste.ms Funds to pay the maintainers you rely on. If you pay these maintainers at least $2000 per full-time equivalent developer you employ per year, you'll be eligible to become a member of the Open Source Pledge.

Ready to become an Open Source pioneer?

Join the Pledge

Open Source: Deceptive Power or Collective Governance?

Vlad-Stefan Harbuz — Tue, 10 Jun 2025 17:00:39 GMT

In October 2024, it emerged that WordPress co-founder Matt Mullenweg has extensive power over the entire WordPress ecosystem, which 43% of all websites on the internet run on. When he exercised this power by seizing control of code that runs on tens of thousands of websites, the WordPress community realised that it was not in control of the software it was using, despite this software being Open Source. And many people were very upset!

This topic has received a lot of media coverage, as well as two thoughtful analyses from our own Chad Whitacre.

But I wanted to answer a very specific question. Can Open Source norms protect us from this kind of deceptive centralised power? Or do we need a different set of norms to ensure that we can collectively govern our software?

I gave my answer in a 10-minute talk at AltCtrlOrg, a side conference to WordCamp, in my lovely former home of Basel, Switzerland. You can watch my talk below.

Almost immediately after my talk, a group of WordPress community leaders including Joost de Valk got together to announce and launch FAIR — a package manager that provides direct answers to almost every one of my points. I'm optimistic that FAIR will pave the way for collective governance in the WordPress community, and I believe that the WordPress leadership team is also receptive to these ideas.

The Open Source Pledge is so important in these kinds of situations. Community initiatives, combining innovative technology and forward-thinking governance, sometimes pop up — but without funding, it's difficult for them to survive.

Companies that depend on ecosystems such as WordPress should help these ecosystems flourish, by financially supporting the most promising initiatives. I hope FAIR will be successful and inspire a movement of collective governance and distributed funding.

(My slides are also available.)

Can your company do its part?

Join the Pledge

We should fund the software we use, not just the software we see

Ben Nickolls and Andrew Nesbitt — Mon, 09 Jun 2025 18:28:27 GMT

Pull Request is our guest contributor series where we highlight Pledge member companies and OSS ecosystem allies.

At FOSDEM this year Ben (Open Source Collective) and Andrew (ecosyste.ms) spoke about a decade of working together in open source sustainability and ‘digital infrastructure’.

In that time they’ve built tools (libraries.io, octobox.io, 24pullrequests.com) to help Open Source developers directly and, most recently, a set of digital services and data sets to aid and accelerate the work of policymakers, researchers and developers building toward a secure and sustainable future for open source, called ecosyste.ms.

Their most recent release, Ecosystem Funds, was built atop these services, in a matter of weeks, as a direct response to the Open Source Pledge. So we thought we’d invite them to tell us what it is, and why they’ve spent the past six months perfecting their process — including the distribution of $75k of funding from Sentry.

- Chad

With the lede thoroughly buried (thanks Chad!): yes, we’re here to talk about Ecosystem Funds, our take on the ‘fund the entire ecosystem’ playbook that others (StackAid, thanks.dev, FLOSSBank, BackYourStack and many more) have released over the past decade. While we support all of those platforms through the tools and services available at ecosyste.ms we wanted to offer a one-stop-shop for funders struggling to understand their core open source dependencies, and to develop and support the entire ecosystem of funding solutions while we do it.

What are Ecosystem Funds?

Essentially Ecosystem Funds are curated sets of open source components that are the most critical (that is, most used) in their respective domains. We built funds at various levels of depth — there's a Fund for Django, and one for the entire Python ecosystem — so that open source funders can make an informed decision about which projects to support, without having to do months of work to understand their software estate, and the mass of open source that’s critical to their work.

The slogan version of that is: We turn a three month audit into a five minute conversation with your CTO or VP Engineering.

How does it work?

From there we run the entire process for funders. No, really, we do.

We accept donations, allocate 100% of the funds to projects on a monthly basis, and manage the process of getting those funds to the maintainers using the platforms they choose to accept funds.

We support all funding platforms. Whether a maintainer uses GitHub Sponsors, thanks.dev, Patreon, Kofi, or any other platform, we direct donations where projects want to receive them. If a project has not indicated a platform in their funding.yaml we encourage them to look at the options available to them. Once they have chosen one, we direct donations there at the end of the month. For projects that do not choose a platform, we distribute funds directly to maintainers using Open Collective.

That might sound like a lot, but our partnership with Open Source Collective is the key: Ecosystem Funds is driven by the data-led approach of ecosyste.ms, which tracks 230m repos and billions of individual events, and Open Source Collective, who move ~$25m annually on behalf of their 2,500 member open source projects. Ecosystem Funds effectively drives Open Source Collective programmatically, instructing the team to make payments, all with double transparency both on each Ecosystem Funds page, and on the Open Collective platform.

But why build another funding tool?

At the launch of the Open Source Pledge we saw a huge challenge for organisations wishing to join: that they would have to decide how to distribute funds, and create a process to do so.

We take all that pain away, while developing and supporting the ecosystem of other funding solutions while addressing the HUGE gap that we have seen in open source funding solutions over the past decade: We’re only funding the software we see, not the software we actually use.

Why should we fund the most used software?

Our view is that, regardless of how you choose to judge an open source project, the projects that are the most used are the most critical. That’s it, end of argument.

But if you need a defence of that position: if your goal is to reduce your risk, or otherwise improve the ‘health’ (I know that’s a polarising term, but let’s go with it for the moment) of your open source dependencies then you have to support the whole ecosystem, not just the projects that appear in a cherry-picked group of SBOMs. If one of the unseen dependencies in your stack fails, your stack fails. And the likelihood that these dependencies, which are typically the most used in a given ecosystem, are your dependencies is extremely high.

In our talk at FOSDEM we demonstrated that there is a huge disparity between funding in open source that we can see, and the actual use (again, ecosyste.ms monitors over 230m repositories and nearly 11m packages) of those packages. We also showed that the usage we see within open source correlates well enough with downloads to say usage within publicly available software is representative of all use. This is key for Ecosystem Funds as we are asking companies to trust that our method for allocating funding will protect them individually.

But we have a problem:

What’s missing?

ecosyste.ms (and by extension Ecosystem Funds) tracks around $52m of total funding for open source projects on Open Collective. It also tracks the funding status (but importantly not amounts) of sponsors on GitHub Sponsors. That is a speck in the ocean of the existing support dedicated to open source today.

The recently embattled NSF’s POSE program alone has distributed hundreds of millions of funding to open source communities, and the projects that they support. But it’s impossible to track the vast majority of resources that are dedicated to open source today, both directly in cash and indirectly through human labour. Without that we cannot make collectively informed decisions about where best to invest our efforts, and our donations.

Without more open data about the support for open source we can never say we are sustaining our collective, critical, digital infrastructure.

So we call on open source funders, other funding platforms, and open source projects themselves to share data, in a programmatically readable manner, about the resources they have today, and the resources they are currently in need of. We pointed to the 360Giving Data Standard, and the Open Contracting Data Standard as two examples of how we could do this today but we are more than happy to lead an effort to standardise this data over the coming months — contact [email protected]">[email protected] to join the conversation.

Finally we would also like to call out the work of organisations like Invest in Open Infrastructure, whose State of Open Infrastructure Report is doing some of the heavy lifting that we need to build a more representative picture of open source support today. We’d love to see more work like this by and/or funded by open source sponsors in the near future.

You can read more about ecosyste.ms at https://ecosyste.ms/ and more about Ecosystem Funds, including how it works, at https://funds.ecosyste.ms/. If you wish to get in touch with Ben and/or Andrew you can contact them at [email protected].

We celebrated Open Source Pledge members in Times Square

Vlad-Stefan Harbuz — Tue, 13 May 2025 08:00:00 GMT

May is Maintainer Month, when we celebrate the Open Source maintainers that make the software we all rely on possible. But we can and should do more than just celebrate, because the Open Source ecosystem we rely on is built on the too-often unpaid labour of these maintainers.

That's why we want to draw attention to the forward-thinking companies that pay the Open Source maintainers whose work they depend on, changing the Open Source ecosystem for the better. Open Source Pledge members have paid $2,650,212 to maintainers over the last year — and that's worth celebrating.

Last October, we [email protected]">featured 20 Open Source Pledge members on the big Nasdaq screen in Times Square.

And last week, we did it again.

13 Open Source Pledge members being celebrated in Times Square

The Open Source pioneers we're celebrating this time around are data science company Posit; CMS creator Sanity, who are powering the blog you're reading; Convex, who build reactive database technologies; API expert Speakeasy; Platformatic, who make tools for Node.js developers; brokerage platform and FLOSS/fund creator Zerodha; performance profiling experts Tideways; developer tool company Pydantic; JS package manager vlt; Python & Django codebase creator SaaS Pegasus; VoidZero, building next generation JS tooling; data grid creator AG Grid; and documentation generator GitBook.

We're also celebrating member company Foxley Talent, a recruiter with 17 years of experience in the Python and Django community — their logo should have been on the screen, but is missing due to a clerical error on our part.

Do you want to do something for Maintainer Month? We think the best way to show your gratitude to Open Source maintainers is to join the Pledge, and make the Open Source ecosystem you rely on safer and more sustainable.

Ready to join these pioneering companies?

Join the Pledge

Open Path Is a New Show About the Gift of Open Source

Chad Whitacre — Thu, 01 May 2025 15:00:00 GMT

Open Source is a gift that's greater than we realize. Truly accepting it could heal the world. That's the premise of my new show, Open Path, which launched today on Syntax. The first episode is pretty personal, about how I came to be leading the Open Source Pledge. I'm hoping future episodes will amplify our attempts to grow the Pledge. Want to be part of the story? Join our Slack.

Why CFOs should care about Open Source software

Todd Bazakas — Thu, 03 Apr 2025 17:07:00 GMT

Todd Bazakas is the CFO at Sentry. Pull Request highlights contributions from Pledge member companies and OSS ecosystem allies.

Perhaps the most important function of the CFO is to control spending. Do whatever you can to make sure the amount of money coming in is greater than the amount going out. So If someone proposes a significant investment, they’ve got a high bar to pass. And if they’re pitching a voluntary investment, one with no immediate, tangible ROI? The bar is in the stratosphere. The concept of paying for Open Source software, which is essentially free, is one such pitch to CFOs that is more likely to be met with laughter than affirmation. But Open Source isn’t free; the cost is liability. After many years of denying my knee-jerk CFO reflexes, I’ve come around to this fact, and I’d like to help convince my industry counterparts that it’s good business to support Open Source.

Open Source software projects are the foundation of nearly every modern business: 96% of commercial software includes Open Source components. That foundation is at risk of crumbling. Most people are unaware that underfunded volunteers maintain Open Source and are under increasing pressure to do more with less.

Adding Open Source investment to the budget protects a company’s bottom line and minimizes security risk. Enterprises realize the collective benefits of Open Source software, and it’s time we collectively support this fragile, essential ecosystem.

A multi-trillion dollar ecosystem built by unpaid volunteers

Modern business wouldn’t exist without Open Source software. It’s an underappreciated building block of the digital economy, with a staggering financial footprint of $8.8 trillion (the cost if every company had to rewrite the Open Source code they use from scratch).

In stark contrast to this financial impact, the people who maintain Open Source are mostly volunteers who are paid very little if at all, and under pressure to do even more as security demands increase. The maintainer population is also shrinking as it ages, with few young people replacing those who step away.

Source: https://xkcd.com/2347/

Burnout is common among this group, who carry the weight of responsibilities at their day jobs in addition to keeping the Open Source ecosystem running. This leaves software susceptible to security vulnerabilities that could be catastrophic. As CFOs, we’d never be comfortable leaving mission-critical business functions in the hands of underpaid, overworked volunteers. Yet that’s what most companies do with Open Source.

Recent Open Source security vulnerabilities like Heartbleed, or more recently XZ Utils, have cost companies millions or even billions of dollars. Companies can’t predict when these situations will happen, but when they do, they are completely exposed. These incidents are becoming increasingly common and will worsen if the Open Source maintainer community dwindles.

Investing in Open Source protects the bottom line

Instead of waiting for the next costly security vulnerability, CFOs should consider how they can support the Open Source projects they rely on most.

Paying Open Source maintainers directly mitigates costly risks: Paid maintainers are more diligent about security practices. Financial incentives could also future-proof Open Source by attracting more young developers to become maintainers.

To get a sense of your company’s dependence on Open Source, start the conversation with the executive leadership stakeholders who build and secure products. Then, include backing your dependency stack as an initiative in the next annual or quarterly planning processes, just like you would to analyze any investment decision. This due diligence will help build the momentum to get buy-in from the board and any other key stakeholders. You’ll need internal conviction that this is the right thing to do; the good news is you’ll likely get nothing but support from your technical colleagues in engineering and security.

Once you have internal buy in, there’s the matter of distributing funds. A stakeholder from the product or development team should lead this effort. The best platforms for distribution are GitHub Sponsors, Open Collective, and thanks.dev. Asking your employees to crowdsource a list of their favorite projects, or even giving them a stipend, is another great way to source recipients and to build morale with the engineering team in the process.

Sentry has always supported the Open Source community—we started life as an Open Source project. Four years ago, we formalized our financial support for Open Source software maintainers and last year, we launched the Open Source Pledge to recruit other companies to join us. 30 have already answered the call and committed to directly pay Open Source maintainers $2,000 per year per full-time developer on their company’s payroll.

As more companies commit financial support to Open Source software, we’ll collectively feel the positive impacts of a stable, reliable ecosystem. Making this kind of commitment is good for business in other ways, too. For example, it can benefit recruitment since a growing number of employees want to work for purpose-driven companies.

The risk mitigation and recruitment benefits of supporting Open Source apply to all enterprises, but if your company’s primary customers are developers, it should be a no-brainer. Contributing to Open Source is an incredible opportunity for brand marketing to a demographic that notoriously hates being marketed to. Universally, developers love Open Source. They know how fundamental it is not only in their day-to-day work, but to the underpinnings of the internet and the global economy.

Paying our dues

Companies in every industry–not just technology–have benefited from Open Source maintainers’ work for years without paying them. Unless we all start investing now, the check will come due in the form of costly security vulnerabilities and a weakening Open Source infrastructure.

Paying Open Source maintainers isn’t charity. It’s a smart financial investment to bolster a system that nearly every modern business relies on.

The PHP Foundation's mission to keep millions of sites safe

Greg Kumparak — Tue, 11 Mar 2025 17:55:00 GMT

A massive chunk of the web runs on PHP.

Wikipedia. Etsy. Every single WordPress-based site, from the personal blogs we all set up in 2008 and largely forgot about to some of the biggest tech news outlets in the world.

If you try to calculate the percentage of websites that run on PHP, the math inherently gets a bit hand-wavey. Lots of sites don’t declare the languages that are running under the hood. Of those that do declare it, the most cited percentage pins it at around 70% PHP.

Whatever the percentage, what I first said holds true: it’s massive. Millions and millions and millions of sites.

Now, most people don’t think all that much about the languages that make their favorite websites work. You’re reading this on a site called “Open Source Pledge” so it’s reasonable to assume that you might think about it at least a little — but the very vast majority of the Internet-browsing population? Probably not.

But languages like PHP are a funny thing. They’re tools for building, but they’re not analogous to hammers and saws. They’re tools that grow, and evolve, and get new features. They (hopefully) get more efficient. Security issues are discovered and (again, hopefully) get patched.

What happens if that progress and maintenance just… stops? If the primary people tasked with overseeing/wrangling/maintaining a language decide — whether it’s due to a new job, or a new interest, etc — to move on?

I recently spoke with Roman Pronskiy, co-founder and Executive Director of The PHP Foundation, about why the foundation exists and why they strive to ensure it’s always someone’s (or, ideally, many someones’) job to know PHP inside and out.

“There was a point around… maybe, 2017 or 2018,” Roman says. “where it was just two people who were getting paid to work on the language. The rest were contributors; enthusiasts working on it in their free time.”

“This entire technology, maintained by just two people? That’s crazy. That sort of thing is fine if it’s a pet project,” he adds. “But if it’s a technology that so many businesses and millions of websites rely on? It’s a ridiculous situation.”

From that realization, The PHP Foundation was born.

“In 2021, I reached out to a few companies in the PHP ecosystem,” says Roman. “Basically, companies that had built their business on top of PHP. I asked them: ‘What can we do about this?’”

The foundation concept was something that had been tried before, but previous attempts hadn’t really gone anywhere.

“I think there was some skepticism about it because it wasn’t the first attempt — actually, this was at least the third.”

This time would be different. Ten companies came on as founding members — including Automattic (the company behind WordPress), Laravel, Zend (an absolutely critical player in PHP’s story, having built the Zend runtime that powers PHP), and JetBrains (creators of the PhpStorm IDE, and the company paying Roman to lead this charge.)

Their day one goal:

The PHP Foundation will be a non-profit organization whose mission is to ensure the long life and prosperity of the PHP language.

This foundation wouldn’t own PHP, by any means — but they’d be stewards of the language, ensuring that there were always multiple people whose literal job it was to understand its innermost workings and improve upon it. The foundation would be funded mostly by its members, from individuals contributing hundreds of dollars to companies contributing tens or hundreds of thousands.

Step one: make sure those aforementioned enthusiasts got paid, then pay more people to make PHP their primary focus.

Why? It all boils down to the “bus factor” — which, to get morbid for a second, essentially means “how toast is the entire project if one core member gets hit by a bus? How much knowledge vanishes?” (Roman likes to capture it in a lighter way, asking “What if one key person decides to go be a bus driver instead?”)

30 years and millions of websites in, PHP is a complex beast. It’s Open Source, so anyone can come in, learn the processes, and contribute code. But it’s not the kind of thing that one can easily airdrop into and start making huge fixes; little changes can have not-so-obvious impacts, so you need people who know how changes might ripple out. People who understand why things are built the way they are.

As Roman puts it: “The learning curve to contribute is… quite steep.”

And there’s a bit more to it than just being good with PHP itself; in many cases, contributors need to understand the underlying C-based runtime — the bit that makes PHP actually do something on the server — and how it all fits together. By increasing the number of people whose job it is to know PHP at its deepest levels, the “bus factor” risk goes down.

Today the PHP Foundation pays ten core developers to work on PHP full or part time. Most of the top ten contributors to PHP, Roman tells me, are funded by the PHP Foundation.

The PHP Foundation's core dev team, as screenshot from its website on 3/11/2025

So what do they work on, day-to-day?

“80% of the work is just maintenance,” says Roman. “Yeah, developing new features, it’s fun — but maintaining things, fixing bugs, fixing security issues, that’s where we have to focus.”

“There’s always something to change… and when you change things, there’s bugs. It’s like a house; whenever you fix one thing, you discover other issues.”

“And continuing this analogy: imagine this house is surrounded by people who want to break in. So while fixing bugs you’re also looking for holes in your fence, making sure the locks are all modern, etc. Hackers attack businesses every day, and find new techniques to attack servers — we fix the security issues, and we organize security audits to pay [outside experts] to come and analyze and proactively prevent these attacks.”

They also help to review code contributions — to check that the code is sound, to make sure any changes are broadly useful, and to help ensure that no one is trying to sneak malicious code in under the guise of helping.

Beyond bugs and security issues, there’s a third, perhaps less-obviously-glamorous challenge to tackle: efficiency. Across millions of sites, even seemingly small improvements to PHP’s efficiency play out in huge ways. “If PHP becomes 1% faster,” says Roman, “it saves millions of dollars across the businesses that rely on PHP.“

But even if they could wave a wand and make PHP perfectly bug free, infallibly secure, and maximally efficient, The PHP Foundation will have work to do in just letting people know about the work they’ve already done. In 2024, a new line was added to The PHP Foundation’s mission statement: "The PHP Foundation aims to promote the public image of the PHP language in the interest of retaining existing and gaining new users and contributors.”

“There are people who haven’t touched PHP in maybe 10 years,” Roman tells me. “But PHP has changed significantly in the last 10 years. One of our goals is just to make sure people understand: PHP today is a modern and well-maintained language.”

Want to find out more about The PHP Foundation? You can check out their website — or, since they handle funding through Open Collective, even check out who’s contributing and how the money is spent.

[The image at the top of this post is based on the PHP logo and shared under a Creative Commons Attribution-Share Alike 4.0 International license]

“Evolving Corporate Reciprocity” at State of Open

Chad Whitacre — Thu, 13 Feb 2025 16:00:00 GMT

Vlad and I went to OpenUK's State of Open conference last week. Following on from Vlad's talk at FOSDEM, I gave a talk at State of Open called "Evolving Corporate Reciprocity." I introduced the concept of a gift economy—a system of exchange based on gifts that carry with them an obligation to reciprocate—and framed Open Source in these terms.

I propose that Open Source is a gift economy, but it's a bad one, because the social norms that go along with it are ill-defined and asymmetrical. Mismatched expectations are bad for everyone. In the long run, it is in all of our collective best interest to clarify the Open Source social contract. The Pledge is one attempt along these lines.

Here is the full video of the talk:

Thank you to Amanda Brock and her team at OpenUK for hosting a wonderful conference with many important conversations about Open Source.

Why and How Companies Should Pay Open Source Maintainers (A talk from FOSDEM 2025)

Vlad-Stefan Harbuz — Wed, 05 Feb 2025 20:50:55 GMT

Chad and I spent the last few days at FOSDEM — the largest Open Source software conference in Europe.

We spent most of our time in the Funding the FOSS Ecosystem track, which was packed with good advice on funding Open Source projects. Ludovic Dubost told us about how 20-year-old XWiki finds funding, Amy Parker taught us about the importance of storytelling, and Andrew Nesbitt and Benjamin Nickolls showed us what you get when you crawl 230 million repositories.

I gave a talk on “Why and How Companies Should Pay Open Source Maintainers”, in which I drew on the philosophy of economics to explain why companies should pay maintainers, then built on my experience at thanks.dev to suggest an algorithmic way to decide how to split up funds across many projects in a dependency tree.

Check it out here:

Many kind folks — some from the Sovereign Tech Agency, ecosyste.ms and the Erlang Ecosystem Foundation — gave me feedback on how these strategies might be improved, so that the Open Source Pledge can help get maintainers paid. Chad and I also met many friends new and old, such as OpenCollective steward Xavier Damman, investor Konstantin Vinogradov and others.

It was great to see you, FOSDEM friends!

How Sanity was created “in a fit of rage”, and why they love Open Source

Greg Kumparak — Thu, 23 Jan 2025 19:00:00 GMT

Sanity is a member of the Open Source Pledge, where companies commit to contributing at least $2,000 per year for each developer on their team to open source maintainers. In this member spotlight we’ll look at who Sanity is, what they do, and why they joined the Pledge.
--------

The founding team behind Sanity didn’t initially set out to reimagine the way content management works for the likes of AT&T, Puma, and a bunch of other companies with household names.

Before they were Sanity, they were Bengler — a product development consultancy out of Norway that explored a wild array of concepts, from an early social network, to better control software for 3D printers (more on that later!), to an experimental device for typing super fast on your phone.

But as more clients came to Bengler for help building out digital experiences, the team found themselves hitting the limits of every content management system they could find. If they just wanted to build a blog? That was easy. If they wanted to build something new and novel with content? It meant starting from scratch each time.

“We were commissioned to do a new kind of web presence for the OMA — the architecture agency of Rem Koolhaas.” Sanity co-founder Simen Svale Skogsrud tells me. “He’s this very famous architect that me and [Sanity co-founder Even Westvang] have been fans of since our late teens. That they contacted us, that they even knew about us, was incredible in the literal sense of the word.”

“We had all of these ideas; all these novel things we wanted to design for them.”

That’s where they started hitting walls.

“We realized all of these [existing content management] systems were just terrifyingly messy — how was this all we have to work with?” says Simen. “Content is data! It’s in a database; I wanted a content API.”

They wanted something where content was flexible by design; where everything they created could be repurposed and reused from page to page and device to device without reinvention. Where the data was clean and beautifully structured. Where real-time collaboration could be baked in, with authoring tools that could be tailored for the needs of each team member.

So they built it for themselves.

“Sanity was created almost in a fit of rage,” as Simen puts it.

“We didn’t actually set out to make a product,” he says. “We just decided that for this first project, we’d have to create something makeshift.”

Then they found themselves using this same internal tooling for another project — and another, and another. “Eventually,” notes Simen, “[One of our customers] said: “Wait, what is this system? Why is this better than anything we can buy?”

Conversations started happening internally: should this be their focus? When a big project proposal came in from the UN shortly thereafter, they had to stop and deeply consider their next move and what they were as a company.

“We were a very comfortable, small boutique agency; we were doing work for incredibly interesting companies.” says Simen. “At that very specific time, the UN wanted us to work on an interactive visualization. We had to decide: are we gonna do this amazingly interesting, well-paid thing… or are we building this system instead?”

“It was this kind of existential moment; we realized that with this idea… there was no point in doing it piecemeal. There was no point in building Sanity as this small, local thing in Norway, or as a little lifestyle business.” says Simen. “That’s when we inverted our business. We decided: this is what we do now. This is not just an internal tool; we’re going to be the people who make this product.”

Turns out they really weren’t the only ones who wanted this: just this month, the company announced they’ve surpassed 1 million projects created with their content tools. (You’re reading this on a Sanity powered blog!)

Screenshot of Sanity Studio, Sanity's open source and customizable tool for creating and collaborating on content

The (Other) Path Not Taken

In another not-too-distant alternate universe, Sanity’s content system doesn’t exist. For a fleeting moment — before customers started asking about this tool they were building projects on internally — they were eyeing an entirely different path: robotics. While it’s not the path they ultimately pursued, it’s one that helped Simen and the team appreciate the reach of open source.

That 3D printing software I promised I’d come back to? In the early days of Bengler, Simen had written software to let machines like 3D printers and laser cutters do more with less.

“I was annoyed that I had to use my whole PC to control these systems. I felt like there needed to be a smaller version of this, so I wrote one for Arduino.”

“I open sourced it … mostly because open source meant free hosting. Then I [looked later] and realized people were using it! And it had kind of become a thing! I realized that it was in almost all of the consumer-grade 3D printers at the time.”

“Even today if you go on AliBaba or Ali Express and search for this software,” he adds, “you’ll find hundreds and hundreds of products that are based on this open source product that I created almost accidentally.”

“I never made a dime for that — which, of course, was totally fine. But I had to abandon that project because it was never commercially viable; I couldn’t pay the bills with it.”

I ask Simen if, years later, that experience might’ve played a part in Sanity deciding to join the Open Source Pledge, as part of which they contributed over $110,000 to open source projects last year.

“[In hindsight] it makes it very clear to me — like in a very visceral way — how not getting paid on an open source project makes it an easier decision to stop working on it. Beyond my initial passion, there was just no way for me to keep working on it.” Simen tells me. “And that’s a danger with any open source project that you rely on — you want people to be able to keep working on it, and to keep that passion up. So when [Sanity’s CEO] Magnus asked what I thought, it was: ‘yes, of course we should do that.’”

Just as crucially, the whole team recognized the key role open source played in them ever getting Sanity off the ground:

“It’s so important for teams like us, especially in the early days. We are still using Postgres. We are still using Elasticsearch. We are still using Golang. These are all open source things! Some of them are very commercial, but these sorts of open source things are what allowed us to get started on a shoe-string budget and establish an architecture that we’re still running on to this day. It’s amazing; it’s not even obvious that that should be possible.”

Within what Simen is saying here lays the mission of the Open Source Pledge: to get maintainers paid for the work they do, so they can keep doing it. It’s good for the maintainers, it’s good for the companies that depend on their projects, and it’s good for anyone who hopes the products they use stay secure and continue to work. In other words: it’s good for everyone.

Want to learn more about the Open Source Pledge and how your company can join? Check out our mission statement.

Distributing Funds in Open Source

Chad Whitacre — Fri, 20 Dec 2024 14:00:36 GMT

Solving the Open Source sustainability crisis has two parts:

unlocking funds from corporations, and
distributing funds to individuals.

Both are hard. I’ve talked elsewhere about the three basic approaches to solving the first problem. The Open Source Pledge is one implementation of one of the approaches.

The primary audience for the Pledge is budget holders at companies. In this post I want to address those on the receiving end of the equation: assuming funds are flowing, how do we distribute the right amounts to the right people? This is important, because, if done poorly, we stand to waste a lot of money and effort without ever fixing the problem of fairly paying maintainers without making them jump through hoops.

The basic model I’m working with is that funds originate with companies, and flow through a series of intermediary entities—whether platforms, foundations, fiscal sponsors, or projects—to individuals.

In fact, there is a complex web of intermediaries, each one an abstraction over potentially dozens or hundreds of component projects, and hundreds or even thousands of individual contributors.

I have two broad suggestions:

We need solid first-level abstractions in order for large companies to efficiently originate funding flows of any meaningful volume.
We need transparent, participatory algorithms and governance models throughout the flow in order for individuals to easily, fairly access project funds.

I’ll unpack both suggestions, but let’s start by discussing the shape of the system in some detail, defining some more terms along the way.

Understanding the Flow of Funds

In Open Source we have producers and consumers. Money is an important gift from the consumers of Open Source to its producers, reciprocating for the initial gift of software. Our desired outcome is that the individuals who ultimately produce Open Source software get paid fairly without having to jump through hoops.

(In my view, Open Source is a gift economy, and market-economic approaches to funding Open Source are subsidization, not sustainability. For other perspectives, see, e.g., Kara Sowles’ talk “The State of Funding Free & Open Source Software,” and Sam Boysel, et al., “2024 Open Source Software Funding Report.”)

Sustainable funding originates from Open Source consumers. Some comes from what we might call “direct” consumers, referring primarily to for-profit companies, but also other types of organizations that directly consume Open Source (educational institutions, governments, non-profits) as well as individual users. This is what the Open Source Pledge is about.

Other funding originates from what I’ll call a “consumer proxy,” that is, organizations with a mission to fund Open Source as a public good. These philanthropies and government agencies fund Open Source in general—not because they directly consume and benefit, but because society as a whole benefits from so-called critical digital infrastructure. Sovereign Tech Agency is our best example. The nascent Open Source Endowment is another.

Some funds flow directly to individual producers of solo projects. Other funds flow to individuals through intermediaries, whether multi-contributor project governance structures, or distribution algorithms.

Projects come in all shapes and sizes. At the tiny end is a solo project that just brought on its first additional contributor. At the other end is the Linux Foundation, a meta-foundation encompassing dozens of sub-foundations and over 1,000 total projects. Most foundations are not set up to pay contributors. Newer ones like PHP are, but older projects like Apache and Postgres simply do not have paying maintainers as part of their culture. They focus instead on marketing, events, fiscal hosting, legal and other non-engineering services. Ruby Central, Python, and Django are somewhere in the middle.

Platforms like GitHub Sponsors, Open Collective, Liberapay, and LFX Crowdfunding help with the logistics of paying projects and contributors. Newer platforms—thanks.dev, ecosyste.ms funds, StackAid—also incorporate their own distribution algorithms based on measures of value and need in Open Source projects. They build on ad-hoc experiments from companies (Microsoft, Sentry) and from generous individuals (Serkan Holat, Konstantin Vinogradov).

What’s more, intermediaries can be nested. So, for example, a company could pay a foundation through a platform according to an algorithm, and the foundation could pay a subsidiary project, which could pay a third-party dependency project, which could pay one of its dependencies, which could pay an individual contributor.

Amidst the complexity, I see two guidelines that can help us collectively iterate towards a workable system. Towards the originating end of the flow of funds, we need solid abstractions in order to scale up funding flows from consumers to projects. Towards the other end, we need forward-thinking project leadership in order to fairly distribute money from projects to individual people. Let’s look at each in turn.

Don’t Expect My Attention

When I buy a cup of coffee, I am not burdened with deciding how much of my five dollars to distribute to the farmer who grew the beans, and the shipping company that transported them, and the roaster that roasted them, and the barista that brewed them, and the suppliers of the cup, the paper sleeve, the lid, the milk, and the sugar. When I buy software from Microsoft, I don’t decide how much of the fee goes to each employee. I pay for a product. We need the same with Open Source. We need abstractions.

Subsidize Open Source: buy this mug.

At Sentry we sponsor upwards of 1,000 projects. Classic sponsorship models such as the original FOSS Contributor Fund require way too much attention to each individual project to work at this scale. This is also the limitation I see with attempts such as Drips, where “anyone can create a Drip List to flexibly send funds to a list of up to 200 open-source GitHub repositories and Ethereum addresses at a time.” Who has time for that? Same with issue bounties. It requires way too much attention at a fine-grained issue level.

I also see this mismatched expectation from individual projects. I hear from maintainers trying to sell me ad space on their README. Sentry does a handful of sponsorships for Open Source projects out of our digital marketing budget, where we’re closely tracking ROI of paid logo placement based on click-through and conversion rates. Our main funding program (the original pattern for the Open Source Pledge) operates at a much higher level of abstraction. It’s a brand marketing investment. I wish I had the time to think about thousands of individual READMEs, but alas.

I need an easy button:

Meter my company’s consumption of Open Source.
Give me an invoice once a year, itemized by high-level ecosystem.
1. Maybe let me fiddle a bit with the high-level percentages.
2. Maybe let my company’s employees influence the result.
Take my money, distribute it, and give me a detailed, public receipt.
Sure, put my logo on a bunch of READMEs, but don’t make me think about it.

How exactly should the money be distributed throughout the network of intermediaries to individual contributors? As a corporate beneficiary of the gift of Open Source looking to reciprocate with money, I want that to be someone else’s problem—someone credible, ideally. I do want there to be a measure of transparency in order to build trust that my money is making it to the right people.

Whether we’re talking about a platform algorithm or a foundation’s governance model, I want the details of how funds flow to be easily available, but not required for me to comprehend in order to pay in. This is like Open Source software itself: how many of us read the source code for the projects we depend on? But we could.

The two leading platform products solving this problem today are thanks.dev and ecosyste.ms funds. I look forward to continued innovation in this product category.

Share Control, Remove Hoops

Consumers paying for Open Source should be shielded from having to comprehend all of the under-the-hood details of distribution. On the other hand, the producers who benefit from funds distribution should be empowered to participate in the decision-making process. Personal autonomy and intrinsic motivation are hallmarks of Open Source participation. Our goal should be to maintain these attributes while optimizing fairness for all contributors. Let’s look at three approaches to this challenge.

Old-Fashioned Hiring at FOSS Foundations

At its most straightforward, engaging in distribution decisions can look like traditional salary or contract negotiations. FOSS foundations have not historically hired maintainers, but this is changing. Geomys hires Associate Maintainers to work on a portfolio of critical Go projects. We’ve seen security engineers hired at Ruby Central and Python Software Foundation. The Linux Foundation employs a few Fellows, including Linus Torvalds himself. The Django Software Foundation dedicates most of its budget to the two members of their Django Fellowship Program. The PHP Foundation explicitly states: “The primary task of the PHP Foundation is to fund developers to work on PHP.” They support ten full- and part-time contractors.

I hope to see more foundations paying maintainers. That said, entering an employee or contractor relationship is a high bar to clear in order for an individual to access project funds, requiring significant interview or vetting processes along with legal and administrative overhead. Not only does PHP fund developers to work on PHP, its contractors submit their expenses transparently on Open Collective. This points toward ways of granting individuals greater autonomy to access funding.

typescript-eslint’s Contributor Tiers

Consider the typescript-eslint project’s Contributor Tiers system. Not only do they publicly pay contributors through Open Collective as the PHP Foundation does, they also document the process by which anyone can incrementally onboard themselves to the project and participate in distribution of funds. Rather than undergoing a cumbersome interview and hiring process, any sufficiently motivated, capable, Internet-connected individual can simply start contributing to the project, with a reasonable expectation of financial return.

The point-based contribution accounting in typescript-eslint’s Contributor Tiers system—1 point for a tiny bugfix, 2 points for a straightforward change, etc.—is reminiscent of the Drupal Certified Partner Program’s contribution credits. The big difference is that the former comes with a direct financial benefit for individuals, whereas the latter confers non-monetary marketing benefits on organizations. What’s more, typescript-eslint is clear about their size: “We treat everything here as approximate numbers. We’re a small enough team to informally discuss changes ad hoc and allow off-by-one-or-two months.” In other words, they operate at a human scale, able to pay attention to the complexities of human relationships.

Cryptocurrency enthusiasts will quickly reach for a decentralized autonomous organization (DAO) to scale up contribution accounting with financial implications beyond the Dunbar number. The concrete example I’m aware of is tea, which got off to a really bad start that reinforces my own skepticism that DAOs are the solution we need. Personally, I don’t think the smart contract exists that could adequately account for all the complexity of human motivation when it comes to Open Source and money. Maybe a DAO might be a useful tool for a project that has already evolved a mature social contract and is ready to scale it further. Until then DAOs are a hammer looking for a nail. Today’s projects should work with simpler systems.

Gratipay’s Team Takes

Ten years ago I conducted my own experiment with money and Open Source, in the context of a startup called Gittip at first, and later Gratipay. It was an early crowdfunding platform for Open Source projects. Our model for distributing funds within a project was called take-what-you-want (twyw).

Whereas typescript-eslint distributes funds based on a detailed, point-based accounting of contributions, members of teams on Gittip had direct access to a weekly budget. Only the individual could set their own take, but everyone could see what everyone else was taking. Individuals had full, immediate control over both sides of the equation: the effort they contributed to the project, and the money they withdrew. I concluded that, properly managed, twyw can be a fantastic way to optimize fairness in a high-trust environment without ruining intrinsic motivation. Liberapay, a fork of Gratipay, continues to offer a modified “team takes” implementation.

Assuming we are able to get funds flowing from Open Source consumers in the first place, the lowest-friction way to get paid fairly as an individual contributor will be to create valuable solo projects and sign up for platforms with weighted distribution algorithms. This might suffice to pay the rent for the most productive developers among us, but we need a richer ecosystem than that. We need multi-contributor projects involving many people with different skills, personalities, ambitions, and circumstances. Larger projects should continue to explore distribution methods including traditional hiring or contracting, contribution accounting, and take-what-you-want.

We Have Time to Get This Right

Unlocking corporate reciprocity for the gift of Open Source is hard. So is distributing funds to the right people, to fairly reward past contributions and best incentivize future value creation.

Corporate consumers connect to individual producers through a complex web of intermediaries involved in the flow of funds. As efforts such as the Open Source Pledge, Sovereign Tech Agency, and Open Source Endowment increase the volume of funds through this system, we need to iterate on the producer side to keep pace. We need to develop solid, trustworthy abstractions to streamline the process for companies paying in, and we need to build transparent, participatory algorithms and governance models for individuals to access funds in line with their contributions and with minimal friction.

The good news is that we have time. Unlocking orders of magnitude more funding is the work of years, and will develop together with forward-thinking leaders building platforms and projects capable of handling the responsibility of a significant budget increase. Together we have a generational opportunity to put Open Source on a firm gift-economic footing, in harmony with its essential nature while gracefully interfacing with the global market economy.

Join the Pledge

David Cramer — Tue, 08 Oct 2024 11:00:00 GMT

Today we officially launch the Open Source Pledge.

The Pledge started as an idea some years back: what if we could give back to Open Source on behalf of every employee at Sentry? We threw around a number of ideas on how we might do that, but none of them seemed like they’d achieve the level of impact we wanted. We always had two core goals with it:

Pay maintainers, directly.
Do it sustainably, and scale it with our growth.

My earliest thought in this space centered around a form of donation matching. The hope was we could take something like GitHub Sponsors and match employees’ contributions to Open Source maintainers. That posed a number of challenges, but the biggest risk was participation. Not everyone cares about Open Source (that’s fine!), so donation matching breaks down with reduced participation. Instead, we decided to do direct funding, driven by a variety of inputs (our dependency graph, projects people voted on, and guidance from engineering leadership).

That program is what you’ve seen from us publicly, running it for three consecutive years. Each year we increased the funding amount based on Sentry’s own financial growth. It became such a no-brainer within Sentry’s leadership that we have aggressively increased the funding each year, even beyond our original targets. With the success of that, we set off to take that program, codify it, and bring it to other companies to see if we could turn this into a bigger thing.

Lead by Example

As we started talking about this, thinking about how we might turn it into something bigger with more impact, I was reminded of a number of scenarios that I had personally experienced when speaking with other founders. I regularly speak at a variety of events, many where Open Source is a key part of the narrative. They’re generally filled with venture-backed founders telling their story of why Open Source matters to their business, why they believe, and invest in it. One thing that was commonly expressed by these folks was the sustainability challenges in the industry. “Great!” I thought, “We have a solution!”

Not a single one of those founders did anything more than talk about the problem. Sure, maybe they throw a few bucks at one of the big foundations, and they almost certainly fund investments into their own ecosystem (their commercial interests). Unfortunately, they rarely do anything measurable that improves the thing they claim to care so deeply about. Worse, some of these people (often from the largest tech companies), have a laundry list of excuses for why giving money to people is hard.

So we decided to try and do something about it. That something is the Open Source Pledge. We don’t think it’s the only solution, nor do we think it’s the only way to give back, but we do believe giving cash money to maintainers is an appropriate way to show your thanks, to recognize their hard work, the value they create for you. Maybe, just maybe, we’ll do our small part in encouraging the maintainers to keep putting up with us in the enormous ecosystem we rely on.

How to Pledge

If you’ve made it this far, there are probably two questions you have.

First, what does it take to join the Pledge? You commit (with receipts) to giving 2,000 USD to your dependencies, per engineer you employ, every single year.

Sentry has ~135 engineers on staff, meaning our minimum commitment is $270,000 this year. Think about that in the context that Sentry generates more than $100mm in recurring revenue. It’s a fraction of what we spend in any given calendar month on digital advertising. It’s a pretty modest amount in the grand scheme of things, but it’s enough to have genuine impact.

Second, what’s the ROI your company gets from joining? It’s marketing. It’s your brand. It’s top-of-funnel. It’s software security. It’s free software. It’s Open Source.

We see ROI in two major ways: brand marketing, and the supply chain. You may care about one more than the other, so choose whichever helps you get over the finish line.

From the supply chain angle, you’re encouraging maintainers of the software you use to continue to provide support. You’re telling them that you value their work, and the contribution is there to encourage them to keep contributing to it. At the very least, you’re giving them a big thank you, setting the tone for future generations of maintainers. You’re thanking them for free software. Both of those improve the efficiency of your R&D investments.

From the brand angle, it’s what you make of it. If it’s a space you care about, you are putting your money where your mouth is, and your audience will recognize that. You buy products from brands that you connect with, and if your customers care about Open Source, you’re giving them one more reason to care about you over your competition. You’re also putting yourself out there, attracting new eyes to your brand that may not have heard about you before.

We don’t yet know if the Pledge will be successful, but I’m thrilled with the number of people who have decided to support the program (directly with funds, and indirectly with broadcasting and recruiting). I especially want to thank the people who have put in the hours to really get this off the ground: Chad Whitacre and Michael Selvidge from Sentry, as well as Vlad-Stefan Harbuz and Ethan Arrowood.

While Sentry is funding getting the program off the ground, we’re hoping it lasts well beyond us and turns into something much more. The industry is in a rocky place these days, and a little bit of effort from the people who can afford it can go a long way.

The Philosophy of the Open Source Pledge

Vlad-Stefan Harbuz — Mon, 07 Oct 2024 23:00:00 GMT

Today, we launched the Open Source Pledge. Virtually all companies use Open Source software, making the Open Source ecosystem crucial to virtually all of the technology we use. That Open Source software is created and supported by maintainers. But the companies that use Open Source software almost never pay the maintainers anything. This means that the maintainers end up doing a huge amount of work for free, often as a second shift after their dayjob so that they can pay the bills, leaving them burned out and overworked, and leaving the projects they maintain at risk of serious security issues.

The Open Source Pledge aims to change that, by getting companies to pay the maintainers of the software they rely on. We launched the Pledge today with the support of 25 wonderful companies and 6 large foundations.

I’d like to talk about why the way the Open Source ecosystem is organised harms both maintainers and companies. I’ll explain how companies can not only do the right thing, but also make sustainable and impactful investments in the Open Source ecosystem. And I’ll talk about why this means that companies that do not pay their share act uncaringly and shortsightedly.

The Problem

The device you’re using to read this post runs Open Source software. There are some high-profile projects that any computer is basically guaranteed to be using — curl, OpenSSH, Python, and so on. These high-profile projects are often, but not always, able to secure funding for their development.

But there are tens of thousands of projects, making up the vast majority of widely-used Open Source packages, that never get more than a few dollars of funding, despite being relied on by companies such as Adobe, Amazon, Apple, Facebook, Google, Mastercard, Microsoft, Netflix, Sony, eBay, and many many others. These companies do not pay back their fair share — in many cases, they pay back nothing — to the Open Source software developers whose work they continue to monetise and depend on year after year.

For example, without FFmpeg, YouTube wouldn’t work, yet the people who make FFmpeg don’t meaningfully get paid by Google or by anyone else.

FFmpeg's tweet on 20 Oct 2024

There’s more. Though the maintainers of Open Source software are often not paid for developing this software, creators of widely-used internet infrastructure such as Elasticsearch can set up hosted versions of their software that they can sell as a service, in order to be able to afford to fund further development. But even this is made difficult by monopolistic free riders such as Amazon. Elasticsearch was previously Open Source, but had to change their license to a non–Open Source one when Amazon took Elasticsearch and started selling it themselves, using their massive scale to take revenue from the original creators of the software. These kinds of moves leave the people who maintain our internet infrastructure unable to earn an income, while enriching profiteering and mooching corporations who don’t give back, such as Amazon.

Basically, the people who make the software we all rely on don’t get paid. This xkcd comic sums it up nicely:

xkcd #2347 — Dependency

This has bad consequences for all of us. Putting maintainers in a position where they’re overworked and vulnerable to burnout renders the Open Source software we rely on vulnerable. There have been multiple serious worldwide security issues because of bugs that are demonstrably a result of overworked and underpaid maintainers. The XZ backdoor, which affected billions of devices worldwide, happened because Lasse Collin, the maintainer of XZ, was overworked and underpaid, and ended up being forced to accept “help” from someone who turned out to be a malicious contributor who would go on to add a backdoor to XZ. And there are other examples, such as the Log4Shell vulnerability, where underpaid maintainers doing their best to fix a major security issue were rewarded with death threats.

Analysing the Problem

So why, specifically, is the status quo of Open Source funding bad? Two reasons.

#1: It’s unfair and uncaring. People like Jordan Harband, Josh Goldberg, Filippo Valsorda, Caleb Porzio, and thousands of others, build software billions of people rely on, but have to jump through a million hoops to pay the bills. This is unfair because these developers contribute massively to our tech infrastructure, and companies don’t support them. Why is it uncaring? To care about someone means approximately to be motivated to act when they might be harmed, even when you personally stand to gain nothing. Companies happily profit off of Open Source maintainers’ work, but do not care when these maintainers struggle to pay the bills.

#2: It harms our tech infrastructure. If we do not support the maintainers of the software our phones, games and airplanes run, we will continue to drive away maintainers, leaving our tech infrastructure neglected, un-innovative, and vulnerable to serious worldwide security issues.

The Solution

There are many possible solutions. Governments could support Open Source developers with tax money, which is what Germany is doing with the Sovereign Tech Fund. We could add tooling to the Open Source ecosystem that makes it easier for maintainers to sell their work, which is what Polar is working towards.

But there’s a really obvious solution that we can implement today. That’s for companies to pay the maintainers of the software they rely on. “Pay”, not “donate”, because payment is already overdue, and it has been for a long time.

This is what the Open Source Pledge is — a cultural movement asking companies to pay $2000 per employed developer per year to the Open Source maintainers they depend on.

Some companies might say that they already contribute in other ways. They might contribute by allocating time for their employees to contribute back to Open Source projects, or by offering Open Source maintainers cost-free use of cloud services. These contributions are great and should be celebrated. But they fall short in one important way — they do not help underpaid maintainers pay the rent.

Here’s one obvious question, though. Why would companies make these payments? There are three big reasons.

#1: It’s fair and manifests care. Companies might care about the fact that the developers whose work they rely on are suffering, and they might therefore be motivated to correct this. This sounds good, but it’s relying on a lot of goodwill. This is fine though, because there are two other big reasons.

#2: Signalling thought leadership. Companies that join the Pledge can signal their thought leadership by being one of the innovators driving a paradigm change in the funding of the Open Source ecosystem. This benefits the company’s brand and reputation, which appeals to potential customers.

#3: Ensuring companies can base their products on a healthy foundation. If the Open Source ecosystem that companies rely on starts crumbling, this is bad for those companies, because they will have now built their software on top of a poorly maintained foundation. Paying money to ensure the software they use is innovative, secure and well-maintained just makes sense.

What’s interesting here is that reasons #2 and #3 involve companies making payments for something that they expect to gain future value out of. This is what we call an investment, and paying Open Source maintainers is a particularly good investment. Venture capital firm Accel agrees, which is why they support the Pledge.

The corollary of the above is that companies that do not pay the Open Source maintainers they rely on act uncaringly and short-sightedly. Unfortunate!

How We Can Implement the Solution

I think many companies want to do the right thing. And paying maintainers is something that companies can do today, by joining the Pledge. The Open Source Pledge does not handle any funds — we simply facilitate money being paid directly to maintainers. Sentry has joined the Pledge, and will be giving more than $500,000 this year directly to the maintainers it depends on, continuing a tradition it has kept up for the past 3 years. Antithesis has given $186,000. We have members ranging in size from 135 developers, to 1 developer. And many other companies will follow. If our current members can do it, other companies can too.

Some companies might worry that it is too logistically complicated to figure out which maintainers’ work they depend on, then figure out how to pay those maintainers. But this process is made simple by services such as thanks.dev, which I am also a contributor to. The Open Source Pledge “About” page addresses many questions companies might have.

If you’re an employee, tell your company to pay the maintainers of the software it relies on. And if you’re a key decision maker such as a CEO, CFO or CTO? Do the right thing — it will benefit you, your brand, and the ecosystem you live and work in.

The Open Source Sustainability Crisis

Chad Whitacre — Fri, 19 Jan 2024 00:00:00 GMT

Let’s get the XKCD reference out of the way, shall we?

xkcd #2347 — Dependency

Okay, now let’s talk about the Open Source sustainability crisis. The purpose of this post is to define terms. What is Open Source sustainability? Why do I say it is in crisis? My answers are that sustainability is when people are getting paid without jumping through hoops, and we’re in a crisis because people aren’t and they’re burning out.

What is Open Source Sustainability?

Open Source sustainability is when any smart, motivated person can produce widely adopted Open Source software and get paid fairly without jumping through hoops.

Consider these four examples:

Jordan Harband is a smart, motivated person who produces widely adopted Open Source software and can’t get paid fairly without jumping through hoops.
Josh Goldberg is a smart, motivated person who produces widely adopted Open Source software and can’t get paid fairly without jumping through hoops.
Filippo Valsorda is a smart, motivated person who produces widely adopted Open Source software and can’t get paid fairly without jumping through hoops.
Caleb Porzio is a smart, motivated person who produces widely adopted Open Source software and can’t get paid fairly without jumping through hoops.

My yearly income milestones as an independent open source person:
* 2022: minimum wage for NYC (~$35k/year)
* 2023: livable wage for NYC (~$60k/year)
* 2024 goal: entry level software developer salary (~$100k/year)

goals.

— Josh Goldberg 💖 (@JoshuaKGoldberg) December 19, 2023

Those are four people at the top of the Open Source game, clearly illustrating that we have not reached Open Source sustainability yet. We’ve hardly begun. For, sustainability means the opportunity to produce Open Source software and get paid fairly without jumping through hoops is widely available to many, many people.

How many? There are 30 million developers in the world. The largest tech companies each employ on the order of magnitude of 10,000 to 100,000 of us. The sustainable Open Source community taken as a whole will be roughly the same size. Open Source is a sleeping tech giant.

1 person sustained - a glimpse
10 people - a glimmer
100 - a milestone
1,000 - progress
10,000 - arrival
100,000 - success

Today we are at zero.

What’s Wrong With Hoops?

Hoops are boring. We’ve had scarcity-based economic relations for millenia. Open Source is designed for a different world. It presents the first real opportunity in our society to begin to develop a post-scarcity economic model at scale. That likely wants unpacking in a future post. For now, I assert that our creative use of well-trodden paths is Open Source subsidization, not sustainability.

If you're interested in monetizing your open-source project, I made this handy chart for you: pic.twitter.com/2yAjCRt78T
— Nate (@eigenjoy) May 10, 2017

As I define it, Open Source sustainability means no hoops, no “New Role” in Nate’s chart. Self-determined individuals freely produce Open Source software, and get paid in proportion to their productivity without having to also become tech influencers, or sell contracts, or any other shenanigans. Those can who want to. I envision a world where we don’t have to.

What is the Sustainability Crisis?

High-profile security kerfuffles such as Heartbleed and Log4Shell often come to mind when we think about Open Source in crisis. But, while they draw attention to the sustainability crisis, the crisis is not about security. Microsoft pays 100,000 developers and still has plenty of security issues. Yes, companies and governments should care about Open Source security, and those efforts can contribute to what I’m calling sustainability, but security is a proxy concern. Let’s call that the Open Source security crisis.

Just as the security crisis is adjacent to the sustainability crisis, so is the Open Source diversity crisis: Open Source is markedly less demographically diverse than software engineering in general. We have not just inequality of outcome but inequality of opportunity. 35% of people don’t even have Internet access yet, let alone free time to hack on Open Source projects. Structural inequalities can be thought of as the largest of hoops to jump through in order to get paid fairly for producing widely adopted Open Source software. We should directly address this wider diversity crisis, and, we should work on resolving the sustainability crisis.

Open Source has created an economic value vacuum. Our society depends utterly on the common pool resource of Open Source software, and this commons is severely underprovisioned. How do we know? The real indicator of the Open Source sustainability crisis as I define it is maintainer burnout.

Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backward compatibility concerns. https://t.co/W2u6AcBUM8
— Volkan Yazıcı (@yazicivo) December 10, 2021

We have a long-standing pattern of chewing people up and spitting them out, as youthful idealism and enthusiasm give way to resentment and depression. We see it most clearly when a high-profile vulnerability shines a spotlight, but it plays out much more widely in less visible circumstances. For example, here is how Marc Grabanski tells his story:

I created an open source component that literally every website or piece of software at the time used, and often still do. Go to the WordPress control panel and there’s my date picker. But in 15 years, the only money I ever got for that was $400 from a guy who needed me to add a specific feature. I think I got a handful of change thrown at me through PayPal, like $50 bucks. There was no economic sustainability whatsoever.

There was a long time where I was doing open source almost more time than my full time job, and getting paid nothing. I just burnt out. I stopped writing and contributing to open source. I never built up my GitHub profile when that came around. I just gave up, because what’s the point when all you get is constant issues? You give and give and give, and people just take and take and take.

My open source success went from a major blessing to a great curse. It was one of the darkest times in my life. Something that started out with such hope and light ended up just being about getting thousands of emails.

There was no viral moment when we collectively realized that we were taking advantage of Marc. We quietly crushed him without ever noticing. There are many such cases.

Update from Marc:

The thing I'd add to that, is I was able to create a network that eventually led to Frontend Masters. My story is not all doom and gloom like it is portrayed in the article. But it def wasn't a given I'd be able to capitalize on the networking opportunities that OSS gave me."

The Path Lies Through Platforms

Funding platforms are critical to achieving Open Source sustainability. Maybe you want to classify “join a platform” under “jump through hoops.” It’s not the same, though.

If you are an open-source maintainer, I would recommend creating an account on @thanks_dev. I've received $268 in 2 months, and the only thing I did was create an account and click on "withdraw". 👍🏻 pic.twitter.com/WHyAA75oRZ
— Nuno Maduro (@enunomaduro) December 29, 2023

Building platforms and recruiting devs to receive free money is easy. The main options today are GitHub Sponsors, Open Collective, and Tidelift. I’m also rooting for Thanks.dev (they are helping me a lot at Sentry) and Liberapay (they are a fork of Gittip/Gratipay).

What’s hard is opening the corporate floodgates. Companies receive outsized value from Open Source, and companies control nearly all the funds. How do we open the floodgates? tl;dr Taxes and social pressure. More on that in a future post.