The Mendicant Maintaineratino holy fools for Open Source
Choosing an “Open Source” license for your work means foregoing the simplest, most intuitive, operationally pure form of compensation—pay for use of your software. People don’t pay to use your work under an Open Source license. Thus unbound, usage and money compensation may radically diverge. A project exhibiting this disparity in force is a successful Open Source project.
In return you get some benefits. It’s easier for lots of people to start using, and come to depend on, your work. If you corner them, they will tell you that you and your project are brilliant. Furthermore, it’s relatively easy to harvest contributions from that larger user base, though few of the many will contribute in any meaningful way—a high-volume, razor-thin-margin kind of play. Overall, the work probably develops in a more enlightened, refined, and complete way, with lots of help finding bugs, avenues of improvement, and communication. If you get hit by a bus, or move on unexpectedly, others have the rights and means to carry on.
None of that pays your rent. As an economic entity, you have, in the most direct sense, voluntarily bowed out of the picture. Financially speaking, all the time you have spent producing the product is, at best, a loss leader.
You can still charge for support. You should. You can still charge for consulting. Do that. You can still charge for feature additions or other spec work. Do that, too. The free use of your work stokes demand for services you can charge for, enabling you to recoup or even, ehem, “capture” some of the value of what you gave away for free. You can use your Open Source cred to land a job, or start a company selling products on top of the Open Source base. In other words, pay the rent.
Unless you’ve a very peculiar, emancipating financial situation, you cannot make great code without paying some kind of rent. There is no way to bifurcate who you are, so the value of the work you do and the economic being you sustain cease affecting one another. It’s insensitive and pointless to expect hungry, desperate people in tenuous day-to-day circumstances to give lavish gifts, like great Open Source code. Creating a runaway success of an Open Source project is as much a game of attrition and tenacity as of skill. There are glorious, glorious exceptions, but odds favor prolific over brilliant, and prolific takes financial staying power. Sweeping in with rent money, at the last possible crisis moment, to save those who walked up to the edge of personal and financial ruin for a passion project that panned out is not an ethical or sustainable model for good software. Generosity is a virtue until it makes a martyr.
So, maintainer friends, remember: Open Source licenses aren’t perpetual services agreements between contributors and whoever shows up needing. Nowhere in the OSI forms appears any free-of-charge support, maintenance, consulting, or training obligation. And, no, there aren’t any such terms in GitHub terms of use, either. Generously selecting an Open Source license does not indenture you to the community, and the false belief that it does hurts a great many people that the community is made of. Know how generous you can afford to be, and that extricating you from a preventable personal crisis will cost much more in treasure and trauma, on all sides, than cultivating a more stable, virtuous cycle earlier on. If you think asking for money for valuable service is hard, wait until you’re stuck asking for money you can’t get on without in gratitude for work you’ve already given away.
To make all this more concrete, more readily actionable, consider a rule of thumb. If you’ve already coded it, slapped an Open Source license on it, and users came later, they can use gratis. That’s implied by what Open Source means. But if users come asking for code, doc, hand holding, or other products of your time that don’t exist yet, start from the expectation that you get paid. When you give time away, do so consciously, and apply the expectations of any other gift-giving occasion. Every day is not Christmas, and you are not Santa Claus.
On the community side, dissipate grasping entitlement wherever you find it. As both a maintainer and a consumer of Open Source software, diligently distinguish persistently funded, institutionally supported projects from what individuals do by collective generosity. In the former case, the severed link between usage and compensation is partially mended, at least for those receiving the financial support. In the latter, it remains broken, and therefore dangerous. Conflating these two very different kinds of circumstances further stokes self-serving expectations about what maintainers of all stripes and situations are supposed to owe whoever’s motivated to make demands, or human enough to forget the other side of the picture. Those faults are universal conditions. It’s shockingly easy to grumble through an insensitive pull request on your own project, then send a similarly irksome issue to another project back in the flow of your own work.
And a word on debt. You may feel indebted to a broader community for others’ Open Source work that you’ve used. But those who contributed code you used and studied before starting your own project didn’t indenture themselves, either. They made the same deal you have—perhaps with the very same license terms—except, for most, there was less parasitic confusion in their time, fewer wheels and levers of social media working to milk “interactions” from them like pump jacks over a vast oil field. Internet passersby have no right to collect on anything you might “owe” to contributors of the Open Source software on which you rely. License conditions aside, that’s absolutely zilch, anyway. Open Source is made of gifts. Gifts are gifts in part because they don’t create debts.
Both failure to distinguish gifts from valuable services and failure to reexamine feelings of indebtedness incur second-order, as well as first-order, costs. Crucially, if your give-and-take is always give, never take, you forego the educational value of learning to do business in the software world. Open Source software development and software work for pay require disparate, though marginally overlapping, skill sets. The hard part in both cases is dealing with people, and the interactions differ markedly. “Innersource” is bringing some of the technical practice of Open Source collaboration to paying gigs. But it cannot and will not make the financial realities of Open Source and profit-driven work the same. Bug tracking and patch politics teach a bit of tact and negotiation, but they will not teach you how to propose a contract, send an invoice, get money, deal with the taxes, or funnel clients ready to pay your way.
True, some of the working difference is perfunctory, a matter of priming the right habits, getting the right systems in place. But paid development work is a deep game, and its nuances are very different. Being good at getting paid to code is different than being good at writing code nobody pays for. Employment, even remote, is not the touch-and-go, asynchronous bedlam of the idealized, mendicant Open Source lifestyle. The rare case of employment to work on Open Source does not void all standards of sane working hours, courteous communication, or professionalism.
Getting good at getting paid for software work does not mean becoming a worse programmer, or becoming a shittier person. Throwing around financial weight in the industry is as much, if not more, an art of self-defense as of get-what-you-can-get, reciprocal plunder. Frankly, those words are a bit too hot. The market is a big machine. Each of us tends our own connection to it, to ensure we’re fed something like our share when it functions as it should. At the same time, each of us resists succumbing blindly to its momentum, pretending it will always mind our values, reducing us to greed-and-social-engineering machines. It takes some supervision, an occasional manual override.
A great many of those most motivated to squeeze time and succor from you, as an Open Source contributor, will be those who mesh their gears very neatly with the awesome, cost minimizing, profit maximizing torque of the business engine, and get overwhelmed in this way for some reason or another. Developers needn’t be fundamentally different people in work as on GitHub, but we all act a bit differently under the very direct pressures of the working world. Perhaps you’ve seen this dynamic at an extreme as folks pleading in GitHub issues or pull requests that specific assistance, if not immediately forthcoming, will land them out of a client, or out of a job, or tank a startup.
I am not suggesting that you write this lot off as mere economic shades, though, yes, I have seen maintainers’ heartstrings tugged as a crass, manipulative tactic. In the main, they will be people just like you, tensely intertwined cords of personal, cultural, craft, and monetary concerns, trying to hold up a balance. Read what they’ve written and understand that they can’t totally separate what they do and feel from what they earn every time, though they might have done better this time. It’s not on you to do their walking for them when they’re caught out weak. But if you’re carrying on as though your own balance is always perfect, you’re probably fooling yourself.
Your thoughts and feedback are always welcome by e-mail.