Where do you go to sell a t-shirt? Shopify.
Where do you go to sell a pdf? Gumroad.
Where do you go to sell code? GitHub?
I love open source as much as any developer. The web (not to mention our society) wouldn't be where it is today without it. The people who created Linux, Git, WebKit, Tensorflow, and more deserve all the recognition in the world. All the key parts of software development today are open source. The next unicorn tech company will be built on the shoulders of open source projects developed by volunteers. On one side, this is what makes the web beautiful. On the other side, we depend on volunteers, donations, or companies sharing the code they've built for everyone.
When the people behind React Router launched Remix, a React framework for creating websites, they launched with a paid yearly license. The license created a lot of discussion in the community.
In this post, I’ll explore some alternative payment models for code. GitHub can empower developers to get paid for code in much the same way that Apple created a new market for apps.
Meet Highsoft, the company behind the web charting library Highcharts. The library isn't widely known outside of data visualization circles, but it's used daily by many Fortune 500 companies. With over 30 employees located in idyllic Vik in Sogn, they are an example of what can be done by sharing code openly but still licensing it for commercial projects. The library's free to use for noncommercial projects, with various license and support options available for commercial use. In 2019 they had $8M in revenue. In comparison, Webpack, the standard build solution for modern web applications, had ~3% of Highsofts revenue.
Over the last three years, Tailwind CSS – a utility-first CSS framework, has grown massively in popularity. In the summer of 2020, it passed 10k installs. The project is open source, but the creators can still live off the project without donations. How? They sell a component library built on top of Tailwind CSS, Tailwind UI, netting over $2M in their first five months.
How can we empower more successes like these?
I see the cult of the free as the web's original sin. To my mind it's an essentially random historical development that could have gone quite differently, but, once the idea of everything on the web being free took root, became a cultural touch point that is almost impossible to dislodge.
There is a cost of free open source software that is rarely talked about. It became more apparent when Firefox had to fire 25% of their workforce during Covid because 90% of their revenue came from Google—their closest competitor.
Recognizing that the old model where everything was free has consequences, means we must explore a range of different business opportunities and alternate value exchanges.
The current payment model for code relies heavily on donations, sponsors, and uncompensated work from dedicated developers. Some companies even hire open source developers so they can work their projects full-time. But this is for the select few. How can we make the web more resilient so that more people can earn money from their contributions to the community?
I don’t want to dismiss open source development in any way. There is no better way to learn code from others, start your career, build up your professional reputation, and get your work in front of many people. But there’s a problem when the whole industry relies on free work and donations from people and large corporations.
I need to make sure that I am building not only a body of work and contributions that I'm proud of, but also financial security for when I can't do this anymore. [...]. Despite having very marketable skills, I don't own a home, much less have a pension and savings in place.
– Rachel Andrew, web developer, member of the CSS Working Group, and the go-to-source of anything CSS Layout related.
One of the largest contributors to open source, Sindre Sørhus, has been funded by the open-source community since 2018. He actively maintains 1100+ npm packages (2 billion downloads a month) and many popular projects. Based on available information from Github, Open Collective, and Patreon, he earns about $52k a year from donations alone. He would have made more by staying in his home city in Norway and working as a postman or telephone sales agent. By comparison, Sindre would easily earn five times as much as a developer with his resume. Luckily for all of us, this is Sindre's answer when it comes to money: «You don't want to be rich — You want to be happy.» Still, I wonder if there is a better way than donations and sponsors to support the great work of developers like Sindre.
Burnout is unavoidable when you're active in open source.
Github is at the center of code and open source. It's where all developers hang out. OK, not literally, but we sure do spend a lot of time on GitHub. They’ve enabled many businesses to build on top of GitHub with their marketplace and GitHub actions. You can pay for SAAS apps that connect to your repo on GitHub and deploy, check your code, monitor your project, and more. But what if GitHub also enabled developers to sell their code on GitHub, not just complex SAAS apps?
Apple's App Store, launched in 2008, now has almost 2 million apps and is visited by half a billion people each week across 175 countries. In 2019 the App Store ecosystem supported $519 billion in billings and sales globally in 2019 alone! GitHub could enable a new market for developers by offering payment for code and creating a distributed revolution.
If you want to sell code today, there isn’t a go-to marketplace. Current marketplaces are outdated and do not embrace today's technologies. Almost every open-source project uses GitHub to manage its code, but you'll receive a zip file if you pay for the code. You get no package management, history, or easy way to get the latest version. Solutions like GitMarket are trying to change this, but the best experience would be built directly into GitHub.
Products like TailwindUI and Remix have to spend time developing elaborate payment schemes instead of developing their product. And don't get me started on the intricacies of recurring payments. What if GitHub made this accessible right in their repos? They’re in a great position since they’re already equipped to process payments from developers and their organizations.
GitHub could support selling code in a lot of different ways:
Highcharts, among known names as MySQL and MongoDB, have an open-source license and a commercial license. If you earn money from the code, you have to pay for a commercial license (yearly usage or a one-time fee.) By making it easy and frictionless to pay developers for using their code in a commercial project, GitHub could enable developers to get paid for their work without the customer having to jump through hoops or pay for something without knowing its value up-front.
Paid extra features, plugins or repos
Tailwind UI, the component library built on top of Tailwind CSS, would benefit from being a paid upgrade for Tailwind CSS. It would also reach more customers if it were front and center where people interact with Tailwind. Another option is closed repos that open when you pay for them.
Example of how it could look with a commercial license
NPM downloads code to your local environment based on what you have specified in a JSON file in your repo. Most packages are free, but you can also distribute private packages on NPM. This is where GitHub could monetize in the Terminal itself using your GitHub credentials and card info. If you add a paid package to your package.json, you’d be prompted to pay for it from the command line. If you paid for it on GitHub, you could download it immediately. This would also open up new licensing opportunities, like paying for code usage.
Sketch on buying open-source in terminal
Voluntary Open Source Tax
GitHub already has a solution for sponsors, but the acquisition of NPM got me thinking that GitHub could automatically distribute developers' money. Let's say you pay $40 per month for supporting open-source code. GitHub could then distribute this money based on all your active projects and which code is actually used.
Paid technical support
We've all been stuck on a code problem where the documentation is lacking, or you need help getting further. What if you could request paid technical support directly in the repo causing the problem? Win-win. You get the best person to solve your problem—they get paid to help and learn how to improve the project further.
They could also offer to pay for certifications, bug bounties, or training and courses directly connected to repos, but I won't go further into that space in this article.
Sketch on paid technical support connected to repos
It starts to get truly interesting when GitHub gets multiple projects funded through their solution. GitHub can then forecast money for yearly payments and provide more liquidity for developers, much like Pipe does for SaaS businesses.
Despite GitHub's popularity with enterprise users, individual developers, and open source projects, it never turned a profit before Microsoft bought them in 2018. GitHub's primary revenue source today is paid accounts, which allows for private repositories and several other features that enterprises need. By enabling their users to sell code on their platform and take a small cut of that revenue, they’d empower their greatest assets and fans, developers, as well as increase their earnings. GitHub provides a lot of value for developers, and it's time both Github and developers capture it!
GitHub has many paths to create an ecosystem around a marketplace for code on their platform. They have already started with their donation feature, which now also supports one-time payments. I’m not sure which approach is best. Still, I am pretty confident that if anyone can contribute to enabling a paradigm shift around paid code, GitHub is uniquely positioned to do so. In my mind, this is very much a case of "a feature, not a product." By leveraging the massive amounts of developers and code already on the platform, GitHub can do this in a way that developers on both sides of the deal will benefit from.
Thanks to Brian Bailey and Robin Sandborg for feedback and editing