At some point I hope to do a talk or blog post about “the economics of programming languages” to talk more about all this in depth, but here’s an overview of some of the things I’ve learned since “Let’s be Mainstream” when I knew a lot less about how organizational structure influences who ends up using a language.
Here’s a job listing for a community engineer for Rust. That’s probably a $100k+ role. A full-time job that requires both technical expertise and great communication skills. Many people will apply, but they will choose a certain person who they think is best suited. If that person gets burnt out, they quit and Mozilla pays someone else $100k+ to do it. This is roughly the job that is most commonly suggested for Elm.
Wait, how does that open-source projects have the money for that?!
Common Funding Methods
Browsers are mostly funded off Traffic Acquisition Costs (TAC) where Google uses some of their ad revenue to pay to be default search in browsers. In 2019, they paid about $30 billion to companies like Apple and Mozilla Corporation to be default search on iPhone, Safari, Firefox, etc. That is about 20% of Google’s revenue, but it was as high as 39% before the Chrome project. Chrome existing and having high market share saves them billions of dollars a year in TAC, and they invest some of that in implementing new features in Chrome. Outside of browsers, voting seats on TC-39 cost $70k a year and are often occupied by people paid to work on browsers. The $100k+ DevRel salaries come from these massive flows of money, and that facilitates the interactions many people expect from Mozilla and Google.
I do not think operating-system funding works the same as language funding, partly because it is more culturally acceptable to do a consultancy like at Red Hat or Ubuntu in that field, but there is still valuable information there. E.g. Linux usus a membership model, partly funded by “platinum members” like Tencent that get board seats in exchange for their financial support. Or IBM that says here:
“We’ve been one of the bedrock members of The Linux Foundation since its inception. We have a long history of doing open source projects throughout many communities. (But) there are things we couldn’t do before that we can now do, working in partnership with The Linux Foundation. “If we were to take a project, open source it ourselves, and expect people to come to that project, that’s a very difficult path. But when you do it in partnership with The Linux Foundation, that path gets smoothed.”
Running an organization the same way as these massively-used projects means selling things. Maybe it is influence. Maybe it is rebranding. Maybe it is default search. Etc. If you are prioritizing adoption very highly, it makes total sense to do these things! How can we settle disputes between Apple and Google about something in Linux? When some new company starts competing with them, what about them? Membership models answer these questions really well, and it gives you budget to have dedicated developer relations roles. It comes with trade-offs though.
When you run a project in these ways, you typically have more incentive to say yes to features. Say that a segment of users wants a
And if you want everyone to use your search engine, having a design process that biases towards adding features makes sense. Everyone can have what they want as a subset and keep happily using Chrome! But I do not think all technical artifacts can be constructed in that way. Over time, you end up with more and more features, but the whole point of some projects is to have fewer features to create a more coherent experience than in projects from the big companies.
I know volunteers in open-source can have their project get to a certain point where they start facing questions about how to prioritize. If you only have nights and weekends, do you add that feature or spend time with your family? Do you try to be a volunteer Community Engineer, or do you go to the gym to work on your weight? I have thought a lot about how to support folks like that in a full-time role so they do not need to make trades like that to meet the expectations of some users, but even if there was a magic wand to get money for that, I’d want to be extremely careful about the long-term incentives it would create.
People are trying funding independent languages in new ways, like Kotlin+IDE and Clojure+consulting and Unison+hosting, with the hosting folks typically having some VC investment. These all have trade-offs as well. Even if it was possible to snap to instantiate any of these models into reality, you are going to alienate people who implicitly prefer TAC funding where you never really need to think about who pays or why, or those who prefer membership models where they know they can pay to prioritize work if it ever comes to that. But what happens when IBM and Tencent pay to prioritize work over many years? There are very serious trade-offs on every path, and paths tend to be quite sticky.
I know Python has shown that you can run community events through a Foundation without creating strong language design incentives, and I have been working since February on getting Elm Software Foundation in order to do something like that (travel grants, Elm Bridges, conferences, etc.) I found a great lawyer to double check things, worked on figuring out accounting, coded up donations via Stripe, etc. I think this is a promising possibility, but since it primarily focuses on supporting community events, I felt that it would be best to present this work after the global quarantines and travel restrictions start to ease up.
I am not saying any other project is running things wrong or that we are running things right. Every model comes with costs and benefits. Every model has different incentives and produces different technical artifacts and communities.
My point is just that people seem generally unaware of how much certain work costs, how it is typically funded, and the incentives that come with the common funding methods.
I hope that subdividing projects by category (language, operating system, package, editor, etc.) and by funding model (TAC, app sales, membership, benefactor, consulting, conferences, etc.) will help people make more appropriate comparisons. Whatever path you take, it will come with obvious benefits and non-obvious downsides. I do not have all the answers here obviously, and I am happy to talk with people who have serious experience with other models to learn more about what can be adapted, what it might cost to do so, and how the relevant relationships were developed over time.