A Failed Effort to Get Paid for an Open Source Project
At a startup of 4 people, our engineering team had to cut many corners to ship the ever-changing list of features we thought we needed. We put lots of TODO comments in our code in hopes of organizing the mounting tech debt. Metadata was thoughtfully added to the comments in hopes to keep things organized, but we quickly lost track of most of it. We had a lot of code, not a lot of people, and the development workflow of building and maintaining our system was quickly becoming less pleasant.
In my spare time, I built a tool for myself and my team: Toodles. It’s a tool that would scan a codebase for all of the TODO entries, organize them, and enable you to make metadata changes that would get applied directly to the codebase’s TODO entries. I thought it was a nifty tool! To my delight, when I put the code on GitHub, others seemed to think so too. People starred, forked, cloned, and downloaded. Toodles started getting contributions from people around the globe, and I was amazed watching it unfold.
Encouraged by enthusiasm from people on the internet and my coworkers, I kept working on Toodles in my free time. Like most projects, the GitHub activity eventually slowed down, but it didn’t go away. I’d get the occasional bug report, sometimes from people who seemed to be working at much larger companies. I didn’t want my software to look or be buggy so I’d fix it as soon as I had time, but the thought would bubble up:
Why was I volunteering my time to a large company? Why was I even volunteering time to my employing company?
After stewing on this question for a while, I came to the conclusion that I could try to charge money for Toodles. After all, I had put in lots of work on a tool that is being used at a company, it’s fair for me to try to be paid for that. Many more questions immediately boiled up.
- Where could a customer buy Toodles? How would I give it to them?
- Was anyone actually using Toodles on a regular basis? Because it’s downloaded and run on the user’s machine, and I hadn’t written custom code to log usage data, I couldn’t even be sure if this endeavor was worth my time.
- If it did have regular users, would any of them actually pay for it?
- If they would, how would I collect a payment from them?
- How could I charge companies money for Toodles, and keep it free for individuals without doing a lot of coding work just for this purpose?
- Is it even ethical to make money on an open source project that other people contributed to, and not pay them too? How could I send money to all of the contributors, or fairly decide how much to pay them?
I decided to first tackle the question of usage statistics. Toodles is a program that would be installed on the machines of its users, so in order to collect any data, it would need to do remote logging to an endpoint I’d have to prop up. Some developers are rather hostile to this idea (for example: https://github.com/lihaoyi/Ammonite/issues/607). I couldn’t use traditional cloud based logging services, since that would require a log collecting daemon on the users’ machines. Setting up my own backend just to collect usage statistics of a locally run application also seemed like overkill. If a proper solution to this problem exists, I still have not found it.
Despite the lack of data and general uncertainty, I decided to move forward and make a paid tier of Toodles targeting companies. To separate the individuals from the companies, there was a cap the number of TODO entries that Toodles would scan, with the threshold set high enough to only be triggered by very large codebases. Because Toodles itself is a server that a user runs on their machine, authenticating a paid user was tricky. I had two options:
- Build or buy a backend system that would track user accounts, purchases, etc, and make the Toodles client talk to it.
- Distribute license files that Toodles could validate in order to access paid features.
Building option (1) was a prohibitively large amount of work, so I wanted to avoid that. A paid service for option (1) didn’t (and doesn’t) seem to exist. With no other choice, I had to go with option (2). I had no idea how to create and validate a license file, but eventually figured it out after a frustrating amount of time. I hoped my efforts would be worth it.
Next, I had to prop up an online store so people could buy a license file. It was tough to find an online store service that could let me programmatically generate a license file when a customer makes a purchase. I eventually found that feature in the e-commerce site fastspring.com. It was tricky to set up. As my rabbit-hole of an endeavor was getting deeper, the return on investment seemed less and less likely to be positive.
After banging my head against the wall long enough to have FastSpring generating my license files, my online store was working. It looked like an online store from the early 2000’s but at least it was working. I set up a simple landing page that would redirect to the store for final purchase.
With the online store complete, I was ready to start selling Toodles Pro! I had to pay FastSpring a large 5% fee on any sales I made, but at least I could make money now. The store didn’t look great because FastSpring didn’t seem to focus on design much, but it was better than nothing. It was functional, but due to all the effort that went into all the setup, it left a lot to be desired.
With everything in place, I waited to see if any of the existing users would upgrade to the paid tier of Toodles. After some time had passed…
Absolutely nothing happened. Zero people have purchased Toodles Pro to date. I realized I’d need to spend a lot more time actually selling this project if I wanted to have any revenue at all. But I wasn’t trying to start a full-blown company with Toodles; I just wanted to capture some of the value that my work was bringing to commercial entities. It became clear that making any money would take a large amount of up-front effort, tangential to my true goals of the project.
So I gave up. There had been too many problems that took or would have taken too much time in order to monetize my open source project:
- Setting up a way to take payments for software was difficult. Even figuring out which platform to use in the first place was difficult.
- Because the payment solution isn’t part of the distribution of the project, simply handling payments wasn’t enough. Now, the application code was tightly coupled to however I managed to implement license generation with FastSpring. License validation and user tier handling had to be baked directly into the code in order to work. Tight coupling of concerns like this sacrifices maintainability and flexibility of the code. It becomes hard to change one without having to rework the other.
- On top of all of the above, assessing if I even should solve these problems to monetize my project wasn’t clear, because I had no data about if/when/how people were using my tool in the first place! I had no easy way to find out, as the software is installed on the machines of the users.
The unfortunate reality was that any time spent monetizing Toodles was time I wasn’t spending making Toodles better for its users. In order to solve this problem for us open source developers, we’ll need a way to distribute our software with payments and usage reporting built in, so the developers can focus just on building and managing the open source project that users love.
I’ll be releasing more thoughts on this problem as I continue to work through it. Follow along for more.
