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 compensation may radically diverge. A project exhibiting this disparity in especially grand measure 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 users will contribute in any meaningful way. The work traces a path of more enlightened refinement, technically and practically speaking, than it would under a different model. If you get hit by a bus, or move on unexpectedly, others have means to carry on without you.

None of that pays your rent. As an economic entity, you have, in the most direct sense, voluntarily bowed out of the picture. The value of all the time you have spent producing the product is, at best, a loss leader, financially speaking.

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. In other words, pay the rent.

Unless you’ve a very peculiar, emancipating financial situation, you cannot make great code without paying the rent from busy-ness that keeps your coding chops toned. There is no way to bifurcate who you are, so the intrinsic value of the work you do and the economic being you sustain cease affecting each another. In the aggregate, hungry, desperate people don’t tend to write good code—or much code at all—and creating a runaway success of a project is as much a game of attrition and tenacity as of skill. Odds favor prolific over brilliant.

So remember: Open Source licenses aren’t perpetual services agreements between contributors and whoever shows up needing. Nowhere in the OSI forms appears any support, maintenance, consulting, or training obligation. There’s no such garbage in GitHub terms of use, either. Generously selecting an Open Source license does not indenture you to “the community” forevermore. Squash entitlement wherever you find it, and ruthlessly distinguish persistently funded, institutional projects that stoke self-serving expectations about what maintainers are supposed to owe whoever comes their way.

In a nutshell: If you’ve already coded it, slapped an Open Source license on it, and users came later, they use gratis. That’s part of what Open Source means. But if users come asking for code, doc, hand holding, or other products of time that don’t exist yet, start from the expectation that you get paid. When you give that 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.

You may feel indebted to a broader community, in some measure, for others’ Open Source work that you’ve used. Those who contributed the code you used and studied before starting your own project didn’t indenture themselves, either. They made the same deal as you have—perhaps with the very same form license—except, for most, there was less parasitic confusion at the time, before the simple machines of social media were composed to milk “interactions” from maintainers like a pump jack pulls oil from a well. 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.

If you fail to follow the code-first rule, at least some significant part of the time, you cannot recapture the foregone educational value of learning to do business after the fact. Open Source software development and work for pay entail disparate, though marginally overlapping, skill sets. “Innersource” is bringing some of the technical practice of Open Source collaboration to paying gigs. Do not confuse that for an increasing identify of financial realities in Open Source and profit-driven, employment work. Bug tracking and pull request politics teach a bit of tact and negotiation, but they will not teach you how to propose a contract, send an invoice, deal with 1099-MISCs, or funnel clients ready to pay your way. Some of the difference is perfunctory, a matter of priming the right habits, getting the right systems in place. But a great deal of paid development is nuanced. 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.

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. A great many of those most motivated to squeeze time and succor from you, personally, will be those whose gears mesh most neatly with the awesome torque of the business engine. Perhaps you have met some of these folks, pleading in a GitHub issue or pull request 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 I’ve seen plenty of examples of heartstrings wrongly tugged as a crass, manipulative tactic. In the main, they will be people just like you, cords of personal, cultural, craft, and monetary concerns tensely intertwined. Read what they’ve written and understand that they can’t separate what they do and feel from what they earn. If you’re acting as though you can, you may be fooling yourself.