Money and Open Source
tl;dr - The current situation isn’t optimal
We need to figure out better ways to fund open source software. This is a problem I’ve thought a lot about over the last few years, and what follows is a long exploration.
A lot of developers do well in a traditional corporate environment. The incentives are clear: work hard, make things better, help the team make the product, and we all win. When it goes well, it’s really nice. You feel like you belong to something, and you can level up as you go along.
But that’s not for everyone. For that simplicity and security, you often have to give up flexibility and creativity. At the very least, it typically limits the reach that your software can have, and thus the value it can provide.
Ever since I’ve gotten into writing Open Source Software in a serious way, I’ve been happier, and more productive. In fact, I was so much happier that I decided I wouldn’t take a job if it meant I had to give this up, and I was privileged and established enough to make that kind of ridiculous decision. It could have ended badly, of course. But lucky for me, I took that time to write npm, and then the gig with Joyent and Node.js came along, and now that’s what I do.
Artists and Nomads
Sadly, many would-be OSS superstars are not as lucky as I have been. Life costs money. The de facto way to get that money is to have a job.
Many employers are willing to “let” their employees hack on their own projects in their “personal” time, or contribute back to projects that impact the bottom line (often with the stipulation that the copyright to the contribution remains the property of the employer). This is not ideal. “Free” time isn’t free;what it costs is your life. Spending it working deprives you of the opportunity to be a complete person.
Some forego the corporate gig, in favor of being nomads and starving artists. They take on minimal employment requirements, if any, and spend the rest of their time being productive on open source. But it’s a rough way to live. Good luck sending a kid to school that way, or even feeding one.
This is a problem for our field, and our society. OSS yields massive benefits to the technology industry, which, in turn, means benefits to all industries, as technological innovations increase efficiency in other areas. However, if the only people who can focus on it are the lucky and the obsessed, then there’s a huge untapped potential.
If we are going to continue to get benefits from Open Source software, and especially if we are going to maximize those benefits further, we have to figure out how to pay for it. Beyond enabling OSS developers to eat and live indoors, payment ties our efforts to the “real world” of transactions, where people use our software to do stuff. Otherwise, it’s all too easy to spiral off into ivory tower lala land.
There are some developments in this area that I’ll mention. Each has some fatal flaws, and I don’t have a ready solution. I don’t think this is a reason to be pessimistic, however. If anything, the fact that we as a society are trying to solve this problem shows that, in some ways, we’re on the right track.
Contracting, Training, Consulting, Etc.
Many developers working on love-projects take short-term contracts. While this is sometimes a great way to make ends meet, I don’t consider it a path towards fundamentally changing the way that OSS is funded.
It is similar to being a traditional corporate employee, but the part-time-ness of the employment simply allows for more “free” time where the worker can do whatever they like. It is not, however, a way that an open source developer can directly profit from their public contributions. Likewise for training and other auxiliary work: it’s not actually funding open source, it’s a job that you got because of your connection to an open source project.
That being said, contracting can certainly supplement one’s other open source activities, in the same way that providing ad hoc services can supplement an early startup on the road to a long-term product.
Dedicated Employee
One way that Open Source projects often get funded is via an employee who spends their official working efforts on the project. This is how the Node core project continues to move forward. Joyent, StrongLoop, Voxer, Mozilla, LearnBoost, and Microsoft employ people who spend all or part of their working time on Node.
(Note: I’m not including here people who work on the project in their personal time. They’re also important, but “do it in your free time” is actually the problem.)
This can work remarkably well, and in fact, can have the positive effect of making the project remain bound to the reality of its biggest users’ needs. When the company writing your paychecks has a problem with your code, you feel somewhat obligated to fix it. Things can get weird when a team works on a software project without any personal appreciation for the end-users’ experience.
Any solution for funding the ecosystem of open source developers should take into consideration these positive aspects. However, there are problems with this approach, as well.
When a community project is driven by a corporate entity, there is often a temptation for the corporation to leverage its position to make changes that are not in the interest of the broader ecosystem. In the long run, this damages the project’s credibility and reach. Bryan Cantrill, SVPEng of Joyent, gave a very good talk on some of the many ways that things can go horribly wrong: Corporate Open Source Anti-Patterns: Doing It Wrong
Even if the corporate stake-holders avoid the obvious pitfalls (and very few do), just the appearance of preferential treatment can be the seed of FUD in the community. Many people in open source communities tend to develop the assumption that all corporate interests are inherently evil. This is an unfair assumption, but given the prevalence of these corporate anti-patterns, it’s not entirely unreasonable.
Also, this solution is only viable in a relatively small percentage of cases. In order to justify a full time employee, that specific OSS project must be vital to the company’s bottom line, and that just doesn’t happen often. Certainly, most companies using Node probably cannot make a sound business case for a full-time employee working on the core project. Hence, the “luck” problem.
Virtual Tip Jars
There are several projects that create a “tip jar” mechanism for showing appreciation. Two that I’m familiar with are TipTheWeb and GitTip. I’m not sure if TipTheWeb is still active. GitTip is a bit newer, and seems to be somewhat popular right now.
Both are based on a moral/ethical framework of some sort. Eric Ferraiuolo (of TipTheWeb) is an unusually kind and moral person, and their goal is to literally make the internet better. Chad Whitacre (of GitTip) also seems to be driven by a strong desire to Do Good.
Leaving someone a tip does feel like you’re Doing Good. It’s a way to show love and appreciation for someone you don’t know well enough to give a “proper” gift. It is spiritually and socially satisfying.
That being said, I’m skeptical that it could ever be a way for more than a few projects to be funded. Could programmers actually pay rent with their GitTip donations? I sure wouldn’t be able to.
The money has to come from somewhere, so I don’t see how this would ever be a way to fund the OSS movement as a whole. At some point, some of the people on GitTip have “real jobs”, and decide to give some of that money to what is effectively a charity. It seems somehow awkward to give someone a tip on GitTip, and then expect them to be beholden to you in any way. A tip is post-hoc; it says, “I like what you’ve done.” It doesn’t say, “I expect you to be there for me when I need you.”
I have nothing against charity. In fact, I think it’s extremely important, just shy of a moral imperative for those of us who are lucky enough to make more than we need. However, when I do the math, and try to figure out the best way to make my charitable dollars have the biggest impact possible on my world, giving $5/month to a software developer just doesn’t measure up. It’s just a game for most people, moving kudos around to say nice things to one another, in the form of tiny dollar amounts.
This could be different if corporate stakeholders were to invest heavily in the developers who create the software they use. But without a quid-pro-quo relationship, this amounts to little more than a purchase of good will. As there are much more cost-effective ways to do marketing, I’m not sure how this would ever make good business sense. Why not just hire those developers, and get much more out of them?
Tip jars are interesting, fun, and feel good. But I doubt they’re going to change the world. There just isn’t enough in there to fund a first-world lifestyle, and I have the sense that if you really depended on tipping, it might skew your motivation in odd ways.
Which brings me to another promising but problematic approach.
Bounties
Whenever we deal with money, we have to be very careful what sorts of incentives we create. Much study has gone into the subject of extrinsic vs intrinsic motivation. If I’m getting paid $5 to do something, I’m probably going to enjoy it less than if I were to do it for free. As Merlin Mann says: “There are two prices: Free, and What It Costs.”
Of course, “I’ll pay $X if you write feature Y for me” has always been a way to get things done in software projects of all kinds. Mostly, in my experience, it has not gone very well. The parameters tend to be extremely ill-defined, despite everyone’s best efforts.
Once the proposed timeline has been wildly exceeded, and no one is satisfied, usually there’s a fight about who has to pay back whom for which bit of work was or was not completed. It’s almost completely awful.
BountySource is the latest entrant into this field, and it’s somewhat interesting. “Backers” can be either individuals or companies. The model uses the idea of crowd-funding that makes a tip jar approach attractive, so you’re not necessarily beholden to a single individual. And, the integration with GitHub issues is clever.
I am extremely skeptical that BountySource will make much of a difference in the OSS ecosystem. What inevitably happens is that the reward is just too low to be taken seriously. However, now that there’s money on the table, The Love is replaced with The Business.
For example, I just learned (in the process of checking out BountySource for writing this article) that there was an $87 bounty on this issue to implement the SemVer 2.0 specification additions.
The thing is, I was already in the process of hammering out the specification with several other people so that I could implement it. (It was overly vague at the time.) Once that was done, I was only able to make it comply by rewriting node-semver entirely. In total, this took around 2 weeks of work, including the spec stuff and the changes that had to go into npm in order to make it behave.
So, while an $87 tip is somewhat nice, I can’t live on $87 for 2 weeks of my time. Even if it was $870 or $8700 or $87000, chasing bounties is not the best way to survive in a sustainable way. It is a last-ditch effort to try to make a community care about your use case. If the community doesn’t already care, then chances are, shifting the motivation from intrinsic to extrinsic may actually make them care less about you and your needs.
The problem with bounties is that software is not often a product with a clear-cut finish. Writing a feature in a software project is more like adopting a kitten than delivering a package. If it’s a kitten you were going to adopt anyway, and someone wants to pay you to adopt THIS kitten rather than that one, then fine, it can work out. But more often than not, it leads to sour relationships and subpar software.
Bounties might make sense as a way for a project maintainer to incentivize others to help out with bugs and features. However, it’s unlikely that a maintainer could put enough money behind it to actually employ developers (and if they can, why not just hire them?) If a project maintainer simply said, “I think feature x is a good idea, patch welcome”, that’s already extremely motivating, and the bounty is probably unnecessary. In the best case, as when Mikeal Rogers put bounties on bugs in Request, it is a marketing stunt which raises awareness, and then that leads to some code getting written.
Bounties seem best suited for cases where there is a clear-cut success metric, like finding security exploits. An Empirical Study of Vulnerability Rewards Programs found that offering bounties for exploits could be more cost-effective than hiring a security researcher. It would be interesting to explore other cases where success can be clearly measured.
However, this is the exception rather than the norm. Companies using open source software typically don’t need a specific feature done as fast as possible, or a set of bugs spotted early. Rather, they benefit most from an ongoing relationship with a programmer who can make sure that their needs are met. It’s not about making a specific change to the program, it’s about making sure that when they need a change made to the program, it can be done promptly. It’s about having someone to call.
Support Contracts
Another means of funding open source is setting up a contract where a user can call on an expert, and that expert will take care of it. That could include logging into the system and debugging a program that’s gone haywire, or helping to figure out an inscrutable error message, or reading the code to figure out how it’s getting into an oddball state.
Much of the reason Joyent pays me is to help debug Node and npm issues that come up in their systems.
I think that this is actually one of the most promising ways that a company can pay for their open source software in a way that makes sound business sense, in cases where hiring a developer is too great an investment in one area.
Companies often use many different OSS projects. If the cost of support contracts for all of them is less than the staff that it would take to support them all, then the company gets the benefit of access to the best developer for any given need, at a reduced price.
Furthermore, at least in the ideal case, the incentives are not so counterproductive. Finding issues in production is unavoidable, but not much fun. If I know that I’ll be involved, it’s in my best interest to write software that is stable, simple, and easy to debug. This benefits everyone, even those who do not pay for the supported version of my program.
Of course, you can still get into situations where the expectations are not met, but it’s a lot easier to commit to “If you pay $X per month, then I’ll respond to your email within 24 hours, and give you up to N hours per month of my time” rather than “If you pay me $X now, I’ll deliver feature Y in 3 months (and it won’t suck).” In my normal day-to-day life, I can still feel like I’m doing my work because I like it, and I’m helping these people because they’re in the category of “customer”. The money is an abstract thing that just happens each month, but it isn’t at the forefront of every interaction.
There are many obstacles to this, however.
As our open source projects get more modular and interdependent, “the dev” might be hard to track down. This can quickly lead to finger-pointing. If you have a contract with a developer who depends on my code, now they’re going to be anxious for me to get my bugs fixed, sometimes in ways that aren’t ideal for my situation. The “subcontracting” arrangements seem to not be worked out so consistently in our industry.
Second, most OSS developers are not well equipped to set up support firms. Knowing JavaScript and DevOps and C doesn’t necessarily mean that you know what kind of support SLA you should offer, or how much you should charge. As a result, developers band together in firms, and go after big companies. The deals get bigger, the sales cycles lengthen, and overhead goes up. This is not in itself a terrible thing; costs are expected on The Enterprise. However, it leaves behind the small- to mid-sized companies, and does not seem optimally efficient.
Since our programs are getting more modular and interdependent, and most developers are not in good positions to sell their services, a third problem arises. Those offering support must be extremely careful about what they are offering support for. If you sell yourself as supporting Node, for example, you certainly don’t want to be making the promise that you can support (or vouch for) every module in the npm registry.
In an ideal (or at least, better) world, these would be solvable problems. There are several chicken-egg issues surrounding this, with a myriad of social and technical aspects that would need to be addressed carefully. How can a customer be sure that they’re getting support from the right people, or that those people are any good at providing the kind of support required? How can you charge enough to make it worthwhile, and distribute the revenue fairly, if no one’s already signed up to provide the support when it comes in? How do you prevent bickering between developers who collaborate on a support request that touched both of their projects?
Getting the right level of transparency, charging the right amount of money, and getting the right developers on board, is a massive problem. I suppose if it wasn’t hard, someone would have figured it out by now. Maybe it’s not actually realistic.
The Future
I would like for Open Source to be seen as a “good job” one day, even (especially!) if you don’t have a “real” job with a company. It would be nice if more people could enjoy a freer lifestyle, without having to sacrifice their financial security. This could also enable new and interesting arrangements, like working part time on a proprietary product, and making up the difference with OSS work.
There will always be a place in the technology industry for people who come together and make a startup, or work for a corporation. I’ve had lots of good experiences working at jobs, often on proprietary closed-source software. However, I don’t believe that it’s the best way for us as a society to most efficiently leverage what developers can offer.
It’s a shame that these artists and nomads are not making more money for the value they produce, and an even worse shame that such a high level of dedication and sacrifice is required for something that benefits the rest of us so much. They are capable of producing tremendous value, but most of them can’t afford the price.
More people could be doing this sort of work, and perhaps be much more productive. But, for reasons of financial necessity, they end up in jobs that don’t often tap their full potential. This is a source of inefficiency. If these potential OSS developers could be unleashed, in such a way that they remained motivated to provide the right value, when and how it’s needed, who knows how much faster we could go?
Appendix: Topics Not Covered
- Why I am More Productive and Happy Doing OSS
- Why OSS is Great for the Tech Industry
- How Open is Open? “Releasing the Source” vs “Open Development”
I couldn’t do any of these subjects justice in the scope of what is already an overly long essay, and my purpose was not to sell OSS here. Watch for these subjects in future posts.
My thanks to Jason Smith, Laurie Voss, Luke Arduini, Domenic Denicola, Deirdré Straughan, and Aria Stewart for reviewing drafts of this essay.
