@radekmieBy Radosław Miernik · Published on · Comment on Reddit
When it comes to open source, I consider myself lucky. One, I authored a few (arguably) successful projects, e.g., uniforms. Two, I worked my way to being a recognized (arguably) community member and core contributor, e.g., in Meteor. Three, I’ve been getting paid to do it since July 2015.
In this text, I’ll go through my open source story and my view on different financing models I encountered along the way. The market is much harder today than it was a couple of years ago, but it may serve as an idea to pursue such financing yourself.
Since my first days at Vazco, I was exposed to working with and on open source packages. I even dug in my GitHub (and BitBucket) history to check my very first public pull request which was on my 3rd day at the company! I was amazed by that back then, and I honestly still am today1.
Of course, it was part of my day job. Or, to be perfectly clear, we simply open sourced a large chunk of our projects immediately. That means your standard task could require a few “public contributions”.
On the one hand, it was a nice thing to do – we “gave back” to the community. I don’t have the numbers at hand now, but we had over a hundred open source packages then. On the other, as it was a part of working on a project, there usually was little to no documentation, no changelog2, and no semantic versioning. A true Wild West, if I may.
I bet it’s not what you think of when thinking about working on open source at work, but for me, back then, it was just magic.
The longer we continued doing the above, the more we realized that it’s not a sustainable process. The sheer number of packages was getting out of hand, so we deprecated some. Projects had conflicting requirements, leading to unnatural configurations, incompatible parallel versions, or hard forks.
Of course, the company only kept growing, and so did our need to share the code between the projects. At this point, we started having more “internal” packages, i.e., following more or less the same process, but as the repositories were not public, it was acceptable to mention project needs in a PR or docs.
That’s also when we started to put more time into writing documentation and examples. It slowed us down significantly, but also brought more stability and reduced the number of accidental bugs introduced in some random URGENT changes for other projects. It all comes with a price, huh?
A few months later, we had only a handful of actively maintained projects3. We still had a lot of projects sharing some of the code, though. All developers were proactively looking for code that could be shared, as this meant less work and fewer bug fixes. (In theory, the same code used in multiple projects benefits from more user exposure and thus is better tested.)
Earlier that year, we started working with React. One of our most essential packages at that time was universe:utilities-react, and it was a Big Thing. We not only used it ourselves in basically all projects, pruning hundreds of lines in favor of only a few using AutorunMixin and SubscriptionMixin4.
It was also the beginning of uniforms. If you look at the first commit made on May 10th 2016, you’ll see a full-blown monorepo (before it was cool!) with documentation, examples, and even unit tests. That’s because it was actually our second attempt at schema-based forms in React. The previous one was a great lesson and got scraped rather quickly.
uniforms got a lot of traction right from the start. Partially because we used it internally in a lot of projects and partially because it solved a very common problem for a relatively large group of people. I think that’s how the best tools are forged – solve a problem you have and share it with others.
Literally two days after the initial release, Alan created an entire Bootstrap 4 theme. It took us some time to get it merged (roughly two weeks), but it was amazing. I felt crazily excited by the community actively working with us and…
I worked overtime. Lots of it. Not because I was asked to, but because I felt like I should. There was a month when I clocked enough hours for a standard, full-time employee. (I was studying full-time and working part-time then.) Yes, I did a lot of extra work for free. Or maybe not, because…
…someone thought that open source developers should get paid. Or maybe they wanted to make a startup out of it, I don’t know. In any case, I stumbled upon CodeCuriosity.org (sample Wayback Machine snapshot) and thought it was an obvious scam. But then I got my first GitHub shop voucher…
In total, I got roughly $400 in gift cards in a year or so. It sounds like nothing, but it felt amazing to get free high-quality swag5 for doing what I was doing. It was also a way of getting new people involved, as, for some reason, developers will do a lot of work for a T-shirt or a pair of socks. (Hacktoberfest, anyone?)
Later that year, I went to my boss to talk about my abundance of overtime. On the one hand, I saw a massive chance for us to develop uniforms further, and I really wanted to continue doing that. On the other, I knew it wasn’t sustainable to continue working this much any longer. (My wife felt that as well.)
We decided that I would get paid extra for my time. It was exactly 16 hours each month, i.e., ~10% on top of my salary. Worked like a charm – I had some extra money, and the company had more open source work done.
Around that time, I also got contacted by some people using uniforms to help them integrate it into their projects. I did some consulting here and there, not only developing the package even further but also getting some money for it. Yes, it was already a nice hourly rate, as it was a proper consulting.
The above continued for a couple of years. I wasn’t the only one getting paid to work on open source in Vazco; there were around three to five people at all times. I don’t remember when it happened exactly, but we went through some internal reorganization, and that’s how the Open Source Group was created.
In practice, only one thing has changed – we started tracking our work in a public GitHub project. We liked it a lot, as it felt better to postpone something rather than reject it. We finally had a way to track priorities between projects.
What’s important is that this reorganization “merged” my entire open source involvement into my day job – no more overtime, but also a little less project work to fit it in. My role at the company evolved as well6, so it made sense.
Like most developers, I often have random side-project ideas. Some of them passed the ideation phase and got published. My first one ever was a single React component focused on looking nice: react-timepicker (October 2015). It wasn’t a hit (I’m not surprised), and I got thrown off a little.
A few months later, I created MiniMongoExplorer (February 2016). I wanted to have such a debugging tool, and I use it to this day. Most of the people I have ever worked with have used it, too. (Not only because I told them to, don’t worry.) It isn’t nice, but hey – it does its job well.
Both gave me some insight into what it means to maintain a project. It wasn’t an internal piece of code I shared along the way – it was something I wanted others to use. It meant the documentation had to be better, feature requests and bug reports had to be handled (at least replied to); some marketing wouldn’t hurt either. I learned a lot, really.
In July 2022, Vazco partnered with Meteor Software (the company behind Meteor). I contributed to Meteor before (e.g., rewrote the entire Minimongo to ES6), but from now on, I have been an official “Core Committer”. However, it was still a part of the Open Source Group time budget, so no extra money.
I don’t know if that’s common for a company owning some open source project to partner with a different company to work on it, but in our case, it made a lot of sense. I believe that both sides benefited from it equally.
When I quit Vazco, I also “quit” Meteor. Sometime later, we partnered directly, which means I’m getting paid to do some work there today. It’s only a dozen hours each month, but it’s enough to review pull requests, discuss potential improvements, and stay active on the forum. Both sides can ask for more or less time if needed, so I can go on vacation or implement something bigger, too.
That was also the first time when I got a decent hourly rate to work on an open source project outside of my day job. It’s not my standard hourly rate, but I’m not complaining – I like doing it. In reality, I spend more time on it, and that’s because there’s some extra money coming from…
I applied for GitHub Sponsors as soon as I could (October 2019). I even got into the beta program, which doubled all of the donations I got during the first year. For the first two years, I got around $200 in total. It’s even less than from CodeCuriosity before (especially if we account for the inflation), but it felt better; more direct. And often came with a motivating comment from the donor.
When I became more (publicly) involved with Meteor, and uniforms got even more popular7, it peaked at $104 each month. Definitely not enough to make a living (I’m from Poland), but it has an additional emotional value.
To sum up, I’ve done open source for free (most of the time), then as a part of my project, as a part of my job (in a way, it was a project on its own), and finally, a separate gig. I got paid on top of my salary and as a part of it, both from large organizations (partnerships) and individuals (sponsorships).
I think the only common funding scheme I didn’t work with is something like Open Collective, where you have to track your expenses publicly. There’s also selling license(s) to your code, which I’m experimenting with now.
Based on my experience, I’d say it’s virtually impossible to make a living only on open source outside of a company. Of course, you can get enough sponsors (or partners), but only a few make it there. And when they do, they usually form some sort of organization along the way.
I’ll keep doing it. For free, if needed. I can afford it now.
I know projects where you wouldn’t even set up the project in that time, let alone commit anything. And committing to a public repository requires extra paperwork in others, too.
I could say we had a “changelog as a service” solution, where your colleague would figure out what has changed in the recent versions for you so the rest could “safely” update it. Once in a while, we even wrote it down!
We simply abandoned the rest and offered only minimal support. Then, we actually archived them on GitHub to make it obvious. (It also saved us time spent on closing issues with a “Yeah, it’s dead.” comment.)
Before hooks (16.8) and functional components (0.14), React had a dedicated createClass-based API, and it allowed you to use mixins. In short, it was a way to share methods and lifecycle hooks between components.
I still wear all but one of the shirts I bought from GitHub. They look great and survived so many wash cycles I believe they’ll last at least twice as long. The “bad” one is simply too short for me now :|
My role was getting more company- and less project-oriented. I also started consulting more and got involved in even more projects than before.
npm’s download counter and GitHub stars are one thing, but we felt it the most in the number of issues being created.