In Debt: The First 5,000 Years, anthropologist David Graeber explores the fascinating history of debt and economies. 

It starts out by debunking the common myth that prior to coinage, everyone were trapped in this inefficient mode of barter.

If you had a chicken to give and wanted sugar from Gandalf, but Gandalf was a vegetarian, you had to first trade your chicken to Frodo, who’d give you the barley, that Gandalf wanted for his sugar.

This is how mosts economists from Adam Smith forward have described what they imagined the primitive, inefficient barter economies prior to the advent of coinage looked like. It’s a great sales pitch for modern commerce, but unfortunately, as Graeber details, it’s also mostly made-up bullshit.

Communities prior to the advent of coinage didn’t seek to settle their trades on the spot, at least not within those communities. They relied on much more egalitarian long-running concepts of reciprocity. Forms much closer to the communist slogans of “from each according to his ability, to each according to his needs” than the quid pro quo paradigm we all take for granted in today’s market-based societies.

The problem, as seen with modern eyes, with early, pre-money egalitarian societies was in part that they didn’t scale. They relied on community bonds to enforce a collective sense of what was good for the group as a whole, backed by the effective corrective measures of family obligations and honor. (Getting ostracized was always there in the background.)

Such a social structure is much easier to maintain at the level of a tribe than at the level of city or nation states. But why? Largely because of the freeloader problem.

The fear that if we don’t feel like we have direct family bonds that tie our shared faith together in pursuit of a common good, society is going to fill up with moochers and leeches. Those who exploit others to do all the hard work, while they enjoy the fruits of that labor.

That fear remains central to modern societies. Witness the evergreen political appeal of pointing out the excesses of welfare kings and queens, or the danger posed by immigration. This is a fear rooted in freeloader fear, which in turn is based on the notion of scarce resources in need of protection. That there’s just not enough to go around! That the party is full.

And humankind does have some reasonable historical scars that have kept it from forgetting the Malthusian spectre. This idea that there really is just a hard limit for how many people a given society can support, before it runs out of resources and everyone suffers.

These scars were formed by millenia of virtually non-existent productivity growth, which kept the human race in check by the constraints of not enough food, and thus constantly being liable to famines, plagues, and other consequences of lives lived at the threshold of subsistence.

Against this backdrop of history, it’s not surprising that the paradigm of scarcity and the fear of freeloaders is deeply embedded in the human psyche. And that it colors most forms of interaction and collaboration, even when doing so is more of an outdated stain than anything.

When I was getting into the industry in the mid-to-late 90s, it seemed like we were witnessing the peak of an epic battle between proprietary and free software. 

This war was embodied at the proprietary end of the spectrum by Bill Gates and Microsoft. The ultimate proprietary extractors, dominators, and conquerers. And at the free-software end of the spectrum, by Richard Stallman and Free Software Foundation. The ultimate software freedom fighters.

And there’s no doubt that these two men were diametrically opposed on many of the key questions about how software should be made and distributed. But that stark contrast also had a tendency to overshadow the way in which they were strikingly similar.

Both Gates and Stallman built their life’s work on the back of copyright law. One with the right to extract gobs of money from his proprietary software monopoly. The other with the right to extract contributions and distribution concessions from users of his open source software.

These rights are founded in a libertarian ideal of ultimate personal freedom backed by strong property rights, enforced by a state apparatus through contracts and courts.

The fact that these arch enemies should share some common ideological base really shouldn’t be that much of a surprise. They were both American men born in the 1950s who attended Ivy League universities, came of age during the oil crisis, and were around for the birth of personal computing. That’s a lot of shared societal forces and context exerted on both with ties to the concept of scarcity.

You might find this comparison a stretch (or even offensive), and I’m sympathetic to the challenge. I don’t mean to equate the two men’s contributions to software, or those of the organizations they led, in terms of virtue or vice. In fact, for the purpose of this discussion, I don’t even think it’s a terribly interesting topic.

What I do think is interesting is how both Gates and Stallman anchored their worldview in a scarcity paradigm that embraced a similar fear of the freeloader problem, and relied on software licenses, that is contracts, to counter it.

Gates was afraid that users would take his software and not pay him for it. Stallman was afraid that users would extend his software and not hand over their contributions.

Both men believed that the distribution of software was a trade exchange. One that had to be bound by certain explicit debt obligations, which had to be settled or else!

Neither Gates nor Stallman were unique in their zeal to control the terms under which their software was used and distributed. Most of the software world fall in the same category. Share the same mistrust of users, and consider some level of debt obligations for using software completely natural.

In fact, when I’m wearing my capitalist cape as the co-owner of the software company Basecamp, I too fall into this category! But when I’m wearing my Rails conductor’s cap, it’s a different story. Then the whole premise of strong property rights and debt obligations starts looking awfully screwy.

Look at the way we talk about the freeloader problem in general in the open source world. We commonly reach for the tragedy of the commons to explain why licenses, contracts, and a sense of explicit debt obligations are necessary.

The tragedy of the commons tells us that individual users will act independently to seek their own maximum self-interest, so if there’s nothing to rein in their native drives, we’re bound to end up with a barren pasture as people just take, take, take, and nobody feels obliged to give.

I believe this is a complete conceptual misappropriation for open-source software development. One that has done great harm to our understanding of what we do as open source software writers.

The magic of software is that there is virtually no marginal cost! That’s the economic reality that Gates used to build Microsoft’s empire. And what enabled Stallman to “give away” his free software (albeit with strings attached). The freeloaders are free! There is no practical scarcity to worry about.

Rails has been downloaded some 170 million times from RubyGems since it started being hosted there. By one account I read, more than a million applications built with Rails have been put online. Neither the first nor the second fact has harmed me in any meaningful way. Not missing the opportunity to collect a tax for each use, like Gates, not missing the opportunity to extract every extension ever made to Rails, like Stallman.

If you accept this premise that there is no tragedy of the commons – that open source software cannot be over-grazed by having more people use it – that freeloaders are free, and scarcity is not an applicable concept, then you’re forced to look skeptically at other assumptions we’ve been starting to make lately in the broader open source community.

Like the idea that open source software just isn’t “sustainable”. That unless we somehow find a new way to force users to “give back” (i.e. pay/donate!), we’re going to burn out people who donate their “free labor”, but won’t do so forever. 

In essence, that we’re at the cusp of a Malthusian-Randesque crisis! Too many takers, too few and too poorly compensated makers!

Never mind the fact that actual, observed famines are so rare that everyone keeps using the same example when it comes to this debate: OpenSSL! A famine that was promptly alleviated as soon as its effects were apparent.

(This is unlike Thomas Malthus who at least had a few millennia of actual, devastating famines to point to.)

The problem with the “free labor” perspective within open source is that it narrowly defines creation and collaboration on the same marketplace terms as proprietary software. That this is an exchange of goods and services.

That by choosing to use a certain open source package, you’re actually accruing real debt to the makers of this software, which you’re really obliged to settle at regular intervals. Either through one-off monetary donations or continuously paid subscriptions.

And even more so, in the vein of an Oracle licensing agreement, your contribution is supposed to scale with your usage or benefit. Like a per-CPU pricing scheme. The bigger the business, the bigger the bill.

But isn’t it ironic that same reality of zero-marginal costs – the foundation of these incredibly profitable commercial software empires – is the same one that allows us to reject the market-based framing of collaboration altogether!

Now, I’m not saying that there’s something categorically wrong with developing open source on market-based terms. What I’m saying is that it isn’t a necessary condition of sustainability. That there are large, successful projects, like Ruby on Rails, that have thrived on rejecting the market-based approach, and is showing no signs of an impending Malthusian doom. On the contrary.

When I look at the literally billions of dollars in business that’s been done on the basis of this thing I started, I don’t look at that with envy or an open mouth. I don’t think “I should have had some of that”. I think what a wonderful world!

I have put something into this world, and continue to put my life into that something, which has benefited a tremendous amount of people. And yes, created a tremendous amount of business. From a grateful twenty-billion dollar business of Shopify to a, let’s say, less grateful twenty-billion dollar business of Twitter.

If my outlook on my work with Rails had been infected by the aggrieved notion of “free labor”, both of those would look like failures. Like freeloaders who got away with it without paying their dues, just because no money changed hands.

Now, if I had this outlook, maybe I’d cut Shopify some slack because of the contributions they have gracefully given back to the community, and continue to do so. But I would certainly look with contempt and anger at Twitter.

Not only did Twitter never contribute any material contributions back to the framework, the company ran for cover under the consequences of their own poor architectural decisions in a narrative that blamed Rails for their troubles. What an ungrateful bunch! What an injustice!

Or… whatever? If I was a Christian, I’d say turn the other cheek. And as an aspiring stoic, I think of Aurelius’ admonishment that “It doesn’t hurt me unless I interpret its happening as harmful to me. I can choose not to”.

Neither Shopify nor Twitter, nor any other company or person, holds the power to cause tragedy to our commons in Rails. There is no tragedy, there will be no tragedy. Rails is a celebrations of a utopian commons. A land where honey and milk spring eternal, or at least unrelated to how many people are tapping in.

Again, I’m not saying this is a universal truth, but I am saying that it’s a possible truth. An experienced and enduring truth for the work and the community that has been happening around Rails.

It’s worth noting that this utopian paradise, where the tragedy of the commons bear no influence on our work, does require a bit of mental self-defense or at least ringfencing.

It’s relatively easy to deal with the distanced ingratitude of a Twitter. As I mentioned, I wasn’t looking for any gratitude in the first place! And nobody from Twitter overtly showed up to demand that I fix their problems. Or to apologize for the fact that I hadn’t or wouldn’t.

It’s a little different when people actually do! Which they do! Or at least did. It’s not as common as it once was, even if I still see it all the time. But here’s how that mental self-defense looked like in the early days:

Back in 2005, this is what the v1 firewall looked like to protect myself against vendoritis. That if I was to release others from being indebted to me for using Rails, I surely had to be released from others expecting me to be indebted to them for using Rails.

You might think that latter release is obvious, but the marketplace norms are hard to escape. They seep into our unconsciousness. There are plenty of open source users who think themselves less as a recipient of a gift and more like customers with warranty claims. That they’ve done the makers of said open source software a great honor by merely choosing to use their thing.

In fact, it’s kinda a natural extension of a society that worships consumerism above little less. A natural extension of “the customer is always right”. Of the adversarial relationship between buyer and seller.
And a lot of open source communities actively entice this sort of thinking and behavior. They’re so over-the-top grateful for attention and adoption that they put themselves in this subservient position.
“Hey, whatever you gotta do to make the sale, right?”

No. Let there be no sale.

I accept how that might seem a little strange coming from me of all people. I used all sorts of commercial marketing tricks in the early days of Rails. There was selling going on, there’s no doubt about that.
But it wasn’t really for a commercial purpose, but rather, dare I say it, an ideological one. Perhaps a more accurate term would have been proselytizing. I was engaged in the promotion of an ideology, a paradigm, and even a worldview.

That might seem like a subtle distinction, and it probably is. But I’m still somewhat regretful that this approach led others down the commercial track, without that distinction in place, and to this questionable end.
Today much of open source is “sold” on these marketplace terms. Everything is slick. There’s your video, there’s your cool marketing site, of course you have a sweet logo. It’s often more than a little hard to see the difference between an open source software package and a commercial one.

I used to think that this was unequivocally a win for open source. That to fight for attention with the commercial alternatives, we had to adopt the commercial playbook. Now I think it’s at the very least a mixed blessing. That if you dress up like a salesman, it’s a little disingenuous to be surprised when people think they’re buying a product.

One way to start swinging the pendulum back towards the days before the commercialization of open source – and I don’t mean that in the sense of Red Hat or whatever, but in the sense of open source thinking it had to out-sell the salesmen – is to look at our founding documents.

This is the MIT license in full, as it was conceived thirty years ago. Twenty lines of light legalease, of which just six deliver the radical punch: Do what you want, do as you please (just don’t sue).

The MIT license is often just lumped in with other open source licenses because of its compatibility with the likes of GPL or other copyleft licenses. That makes it seem like they’re just really flavors of the same thing, but they’re not. In many ways, I consider the MIT license to be as different from copyleft licenses like the GPL as it is from commercial proprietary software.

The MIT license to a large extent is the anti-license. The utopia of socialized programs, one that embraces the lack of marginal cost for software goods.

It’s an explicit rejection of the strong-property rights approach taken by both Gates and Stallman at their respective ends of the libertarian spectrum.

It’s the language of giving without expecting anything in return. It’s the language of sincere charity. A charity without strings attached, neither commercial nor reciprocal. With the risk of sounding sanctimonious, I read it as a pure projection of altruism.

It’s kinda funny to analyze the MIT license from this perspective, because I do remember feeling the pull of a primordial debt to the software community when I started Rails. A motion to give back now that I had something to give. I was born into the software community through the grace of open source, and now I had the opportunity to participate as a contributor, and it felt wonderful.

But it felt like that exactly because there was no sword hanging over my head. Nobody telling me that this is what I ought or had to do. No one expecting me to do it. So it was an act of volition rather than one of duty. A truly authentic choice.

That to me is freedom.

The freedom to first pursue self-actualization in making something in my image. The best I possibly knew how. Again, not as free labor, but as a literal labor of love. As an amateur in the original sense of the word.
Something that in all honesty has been worth far more than money (or reciprocal gestures) to me. And I say that with the clarity of my privilege, but also from having been on either side of that money while working on Rails!
When I started working on Rails in 2003, Jason, my then boss, now business partner at Basecamp, was paying me $25/hour. (In itself a princely sum, up from the $15/hour I was getting paid when we started working together in 2001). I was attending the Copenhagen Business School. I did not have rich parents supporting me, though I did have the backing of a functional welfare state that sees the wisdom in educating its young without trapping them in student debt! Anyway, this was my income, and yet I poured a substantial amount of spare time into making Rails. Hours that I did not bill Jason for!

Talk about free labor!

Except it wasn’t an investment to curry favor with an employer. Or as some shrewd career play for the long term. In fact, I didn’t see it as an investment at all. I wasn’t doing it expecting any external rewards or advantages, then or in the future. It simply wasn’t a project underwritten by a market-based worldview.

On the self-actualization front, it was about the three components of motivation, as Daniel Pink summarized in his book Drive: Autonomy, Mastery, Purpose.

Autonomy to engage with the challenges that I deemed interesting. In the order that pleased me. In a style that appealed to me.

Mastery as a pursuit for its own sake. Learning all the intricacies of this beautiful, sparkling gem of a language: Ruby. Having my mind blown by meta-programming and DSLs.

And finally, a two-fold purpose of using Ruby to build something real, but even more so, to build something that would allow others to pass through these same rings of delight that I had been sprinting through.
Again, not so they could owe me something. But simply to share that delight with others.
That last bit is nibbling at what Abraham Maslow called self-transcendence in the work that proceeding his standard pyramid of needs, with its five layers of progression.

Which in itself is of course but an echo of what’s been said a million times over in history.

That there’s a deep sense of satisfaction that comes from having done work that’s genuinely useful to other people. Again, not in sense of market terms, where you sold someone something useful, and you’re pleased with the transaction. But the absence of transactions altogether.

What’s unique about Maslow’s insight is in how the pyramid of needs help us with a road map to making that happen. Clarifies why we at times do not feel like we’re either able to win for ourselves or to strive to help others win. Because we’re stuck at the base levels. Either in reality, being deprived of security and safety, or in our minds.

I’ll forgive you if you think this talk of self-transcendence sounds either like some religious hokus pokus or some new-age hippie-dippie bullshit. I’m pretty sure that would have been my reaction in 2003, at the age of 23, when I started working on Rails.

Which is kinda the sneaky wonder of Ruby and Matz’s vision. How it echoes that timeless conclusion that Maslow and Mr Rogers and many others have reached.

Matz speaks in the uncontroversial, approachable terms of “happiness”. Who doesn’t want happiness? 

But isn’t it interesting how he’s also between the lines describing the ascendence from self-actualization to self-transcendence.

It’s equally interesting to see how he’s projecting the same Japanese sentiment that’s currently sweeping the world via the phenomenon that is the KonMari method. That the things you surround yourself with are obligated to spark joy. And if they don’t, you should thank them and send them on their way.

This is radically different from the Western ethos of “the best tool for the job”. Of inanimate objects whose sole purpose is to do “a job”, not to spark joy, or really any other emotion, inside our perfectly rational modes of production and cognition.

Inasmuch as we, in the West, refer to software in humanistic terms, it’s generally only in the form of biological metaphors for our components and systems. A lens of science. Very far removed from any sense of perceiving of software as a dance partner in a humanistic waltz.

Matz, on the other hand, is decidedly humanistic in his approach. That is, putting the human in the center, with all our flaws and impulses, and making the machine secondary.

In this regard, Matz draws on a rich tradition of looking beyond rationality as the only virtue worth striving for, or as all humankind needs to thrive.

Natural, not simple. Rational, but not just.

This is what the acceptance of human nature looks like. An acceptance that must see expression not only in our philosophical rumination but in every day life and work.

And I think it’s the failure to do so that breeds much of the discontent and even angst in the minds of many programmers. Stuck as they are in this enlightenment prison of rationality (and libertarianism). Only free to indulge that one-twentieth of life that is our rational side.

This may be true of much of Western society in general, but I think it afflicts software practitioners in particular because of our founding roots in the temples of rationality: Mathematics and physics.

Computer Science is still seen as the primary discipline when it comes to creating software. As our narrator from the underground would say, science is but a twentieth of software development! An important part, but completely insufficient as both a way to understand and to practice software development.

One of the ways that the focus on computer science in software development leads us astray is with the notion of objective truths. When you’re comparing two algorithms for sorting, you can mathematically prove which is better, if you set the terms of the competition. Are we optimizing for speed, memory, or some combination? It’s possible to declare a definitive winner that we can all agree upon, because, you know SCIENCE.

That’s fine. That’s good. That’s science as it’s supposed to work. The problem is when we extend that scientific quest for capital-T truth to the other 19/20ths of software development.

Take static vs dynamic typing, as just one example. When I got started in the late 90s, this was a hot topic. Fiercely contested. Now, 20 years later, it is again (or rather it still is)! Just witness the excitement around TypeScript (and now the inklings of a movement in Ruby for the same). Both part of the continued litigation over its superior fit for creating fault-free software.

This is not a question we’re going to settle with science! Decades upon decades of empirical data have been produced, studied, argued, and yet, we are no closer to declaring a universal victor for either static or dynamic typing. That should tell us something! That we’re using the wrong scale to weigh our options.

The same, btw, is true for objective-oriented vs functional programming. And a litany of other fiercely contested territories in software development.

But if science isn’t going to tell us how best to write software, what or who will? 

The Danish philosopher Søren Kierkegaard might have an answer for us in the paradox of personal truths, which he explored in Fear & Trembling, amongst other places.

That the conclusion to wrestling with the unknowable is to take a personal leap of faith. To find and commit to a set of personal truths to guide our work and our lives. With the understanding that these truths are our choices, not universal facts. That these choices can never be based on universal facts. The kind of answers you seek when you’ve reached the boundaries of science and rational inquiry.

This is really just a strand of existentialism 101: There is no universal meaning to life. You’ve been thrown into the world without a preordained purpose, which is both a terrible burden to bear and the ultimate freedom to embrace. You get to decide.

But you cannot consciously accept that and start your personal search until you give up on the idea that someone is going reveal it to you, if you just read another Best Tool For The Job ode on Hacker News.
Broadly speaking, at this level of abstraction, like static vs dynamic typing or OO vs FP, there is no Best Tool For The Job. Only a Best Tool For That Person At That Moment In Their Life For The Job. A set of personal truths to be discovered / decided upon by each individual practitioner.

That is a seriously frightening conclusion! That you’re responsible for your own truth when it comes to many of the biggest questions at work (or, for that matter, in life). Accepting this burden is not for the faint of heart.
So many don’t. They try to escape from freedom. Overwhelmed, they want someone else to choose for them. And thus we get the endless jockeying for signs of what we’re supposed to do. That is, what others are doing. What’s the hot new thing? How do we measure hotness? Is it number of Google searches? Or most recent release? Or something else?

Oh, please, wise interwebs, won’t you please make my choice for me!

And we keep reinforcing this sense of resignation. I don’t know what I’m doing! I’m not qualified to make authentic choices! Bullshit.

If you keep modeling yourself on the meme of a dog who’s, come on, let’s face it, never going to learn how to program that computer, don’t be surprised if you end up stuck at the canine level of competence.
You’re responsible, yes. But also, you can do this. Yes.

You could say that Rails benefitted from this abdication of freedom for years itself, as it was seen as that new hotness. And I, in my lack of understanding from what actually motivated me to do this work, cheered it on. Look at that new cool startup using Rails! Look at that celebrity-programmer endorsement! Look at those download counts!

How many authentic choices were made during those days? I don’t know. But I’m sure a lot of them weren’t.
Which is a nice post-hoc rationalization for embracing our current stage of maturity as a community. I think it’s much easier to authentically choose Rails today than it was ten years ago in 2009.

In Man’s Search For Meaning, Viktor Frankl describes life in the German concentration camps during WWII. Or rather, he describes the death, and its cause, as he saw it. That humans have an unbelievable resilience and capacity to endure, even in the hardest of circumstances, but only if they can see a purpose. Once the purpose is gone, the will to live extinguished, death soon followed.

From this personal and harrowing experience, Frankl developed logotherapy. His psychotherapeutic method for helping people dealing with a range of mental illnesses, like depression, anxiety, substance abuse. His key belief was that the root of many of these conditions was to be found in existential angst: A loss of meaning, a loss of purpose. And thus, if meaning and purpose could be rediscovered, you’d be addressing the source of the condition.

I don’t think it’s a coincidence that a lot of people in software development struggle with mental-health issues. I think a significant portion of these struggles stem from a core lack of meaning in our work. And the cognitive dissonance that arise from thinking about our industry almost exclusively in these rational, market-based terms.
I think it’s why so many startups in technology are so eager to boast about how serious and important their mission is. Even if it’s evidently not so. They’re trying to counterweight and compensate for the actual loss of meaning and purpose that a lot of us suffer under either periodically or chronically.

For fuck’s sake, Dropbox. You host files. You make the files appear on all my computers. 
I like Dropbox. I use Dropbox. I PAY FOR DROPBOX. But it is not “unleashing” my “creativity” in any meaningful sense of either of those words. It stores my files. It’s literally a filing company. 

Do you think filing cabinet companies of yesteryear bragged about unleashing the creative capacity of the whole fucking world? Of course they didn’t! That would have gotten you laughed out of church.

But now there is no church on Sundays. Just an all-nighter at the startup office. So it’s no surprise that work now feels obligated to tend not just to your needs for making a living, but also for putting all the purpose into that living, since there frequently isn’t room for anything else.

Isn’t that the epitome of the hustle culture that we’re currently in? That you’re stuck feeding these meaning-deprived startups all your waken hours. Rendering it utterly impossible to build other pillars of meaning in your life.

This is the trap of “compress your life’s work into a decade of ‘hard work’”. It’s betting all of your logos (meaning) on a single, unlikely-to-pay-off ticket. And even if it does “pay off”, in the sense that what you worked on is a success, you might still wake up to a crisis of meaning.

Just ask Brian Acton, cofounder of WhatsApp, about that. He made one of the biggest slam-dunks possible when he sold his company to Facebook for $19 billion. And yet, this was how he felt about it in an interview after leaving that company:

As I personally think back on my two decades in this industry, I can recall several instances where I wrestled with this loss of meaning and purpose, and faced both a professional and personal slump as a result.

The first happened when working for an enterprise Java shop back in 2001 that sold community software to large institutions. I wasn’t writing any of the Java there, just HTML/JavaScript/JSP, but I kept being dumbstruck by the amount of hoops and circles we jumped through at that circus to essentially sell phpBB for a million dollars.

My role in that show seemed so insignificant and so utterly pointless. Like, “what am I even doing here?”. A complete lack of purpose, and as a result a complete lack of motivation toward both the work and my own betterment.

I only worked there for 9 months, but it seemed like the days dragged on for weeks and the weeks dragged on for months. In terms of technical skills, I learned nothing. In terms of management and business, I learned everything not to do.

The second instance that stands out was around the year 2009, when I had been working on Basecamp for about 6 years. We had added all the features we thought made sense. All the big breakthroughs and major challenges had been met and addressed. We were left polishing the edges.

At the same time, I was four years into living in a foreign country with an alien culture, and had little in the sense of deep personal relationships to show for it.

There was all this work I could be doing, but I couldn’t bring myself to do it. At the time I couldn’t quite put my finger on why. I just knew that the motivation wasn’t there. So I spent a lot of time procrastinating and seeing weeks go by with no progress. Partly this was because I simply felt I wasn’t needed. Sure, I could participate, but if I didn’t, things would go on just about as well.

The main thing that kept me moving forward, professionally, was working on Rails. I was suffering from what clearly felt like burnout at Basecamp – not from overwork, but from under-purpose – but being able to keep my brain engaged with Rails soothed the soul.

Working on open source, outside of the context of the marketplace and its expectations, was a lifeline.
And thankfully the slump at Basecamp didn’t last. Not long after, we wrote a new book. REWORK. Extracting the highlight reel of lessons and insights from, at that time, a decade’s worth of work in the industry and running our own thing.

Second, we started work on a brand new version of Basecamp. Rewritten from scratch. With all the best ideas as of 2010. Not as of 2003, when we first wrote Basecamp.

Those projects snapped me out of the funk. Suddenly I had a clear purpose where my unique talents as a writer of pithy essays and of Ruby software counted to make a difference.

This is the snowball effect of finding meaning at work. You don’t just have a fixed pie of productivity to divide amongst your pursuits, be they commercial or open source. The pie expands and shrinks depending on your motivation and your mood. When one area of your life is contracting, it often shrinks all the other areas along with it. And when one part of your life is expanding, others often follow too.

It’s a testament to the fact that you can indeed cultivate meaning, as Frankl discovered with logotherapy, and the existentialists have been preaching. That by either changing your circumstances or your outlook, you can create or even invent meaning, which in turn then becomes self-sustaining because it feeds on itself. Doing meaningful work provides for a meaningful life which inspires more meaningful work. It’s recursive!

But if it’s possible for open source to create meaning in your work, it’s certainly also possible to destroy it. Turn that which used to give you joy into that which now gives you dread. The open source world is full of examples of maintainers and contributors who ended up turning a labor of love into just that dead end of “free labor”, and hating the work (and sometimes themselves) in the process!

Let’s return to Maslow’s pyramid of needs and its insights of a supporting bases. Maslow’s insight was that it’s difficult to impossible to strive for the peak of the pyramid if you have not tended to its base. Physiological needs precede safety needs precede … all the way up to self-actualization and self-transcendence.

So when a contributor to an open-source project starts seeing their work lose connection to self-actualization, esteem, or even love and belonging, not only is it impossible to strive for self-transcendence, since that relies on a complete pyramid below it, it’s also what causes someone to retreat to the more base layer of safety needs.

This can happen either because they’re out of ideas for work that they can connect to on a personal level. Because they’ve allowed themselves to think that the “customer is always right”. Or because open source suddenly needs to shoulder their livelihood for one reason or another.

For any of these reasons or others, it’s surprisingly easy to end up feeling like all you’re doing is “free labor”, and how that’s a rotten deal. Because it is! If base needs aren’t satisfied through other means, and you’ve lost connection to your higher strivings, the whole thing quickly devolves into a fight for survival.
And that’s how we get back to the discussion about sustainable open source development.

Let’s start with that word, “sustainable”. Because it sets us up for a false premise right from the get go, if we’re not careful. Its first association pulls us right into that beautiful meadow that we must guard from the over-grazing in the tragedy of the commons. Sustainability is inherently linked with the concept of scarcity.

It’s hard to stop a spiral of aggrievement once you’ve chosen to look at open source development this way.
It’s the way of Stallman and the GPL license. Walking around with the scowl that someone might take your software, and do things with it you wouldn’t like (such as extending it without sharing those extensions).
Which has just never seemed like a very appealing temperament to me. I’m not interested in making software together with people or companies who’d rather not. Who are extorted into collaboration by a software license. Maybe that worked for Linux, but it seems like a pessimistic, angry, and, frankly, counterproductive way to entice, and actually respect, people.

It reminds me of the book The Self-Driven Child in which authors Stixrud and Johnson take the position that rather than acting as a manager, you should act as a consultant in dealing with your children. Nudging kids toward good outcomes, but ultimately respecting their self control.

I’ve been a parent for about six years now. We have two kids and a third on the way. And it’s hammered home the reality of just how hard it is to get someone to do a thing they don’t want to do! And not just hard, but counterproductive, and short-term. You might get a temporary level of compliance, but it’s not exactly an enthusiastic or creative one.

A relationship based on forced compliance is ultimately one that relies on threats, shaming, berating, or worse. It’s not exactly a loving or productive one.

Maybe I’m reaching again here, but if we take the poster child of the GPL, Linux, and we look at the person who’s been in charge there for a long time, Linus, I see a lot of similarities. That of an angry, berating, threatening manager who’s extracting contributions out of collaborators.

I don’t see that as a healthy model.

Now, as we’ve explored, the MIT license is very different. And I think it sets a completely different tone for the working relationship between open source contributors then does the GPL.

But it’s not a bulletproof vest. And if you’re tumbling down the pyramid of needs, and you don’t land until you hit security and safety, it’s still possible to superimpose the debt/rights/extractive value system of the GPL on top of it.

In that context, haunting or shaming adopters for not doing “their part” can start to make sense – at least to the aggrieved person.

Here’s what made sense to me over the past two decades of sustaining an active open-source involvement. This is my personal truth. To resist the temptation to treat my open-source work as a set of transactional, market-based exchanges.

It’s brought profound meaning to my life, and a much needed escape.

And, should your personal pyramid of needs allow it, I invite you to do the same. 

To reject approaching this utopian parallel universe with questions like, WHAT CAN THIS DO FOR ME? WHAT CAN YOU DO FOR ME? AM I GETTING ENOUGH BACK FROM WHAT I PUT IN? WILL IT FURTHER MY CAREER? WILL IT GET ME A JOB?

Open source, as seen through the altruistic lens of the MIT gift license, has the power to break us free from this overly rational cost-benefit analysis bullshit that’s impoverishing our lives in so many other ways. 

It’s a lens that isn’t smudged by the tragedy of the commons. Where we find meaning in our work, and I mean that in the broadest sense, not just as “what you’re employed to do”. To go beyond “Getting The Job Done”, and to connect with other practitioners as other humans, not just as market participants. A way to create bonds free of quid-pro-quo reciprocal expectations.

To borrow a phrase from Stallman, “free labor” under free as in freedom, not free as gratis. Free from demands, free from debt, shame, and repayment.

And, this part I’m still working on, free from having to sell. To reject measuring my worth in the same bullshit measures of engagement that’s driving the wider world off a cliff.

Free to pursue intrinsic motivation from a quest for autonomy, mastery, and purpose that isn’t shackled solely to employment or business.

Free to reach for the self-transcendence that lies in giving away the best of what you got and asking nothing in return.

So. To kick off this mindset, I’d like to borrow an ancient concept from the history of debt. The jubilee. I hereby declare a jubilee for all imagined debt or obligations you think you might owe me or owe the Rails community as a whole. Let no one call upon you to ever feel obligated to repay this vanquished debt. Contribute to the Rails community because it brings meaning to your life. Because writing Ruby sparks joy. Don’t participate if it doesn’t.

Either way, you’re whole and we’re square ✌️

A gratis tablet of dramamine for the nausea of our otherwise market-soaked lives along with an open invitation to make some socialized software together.

—
I originally wrote this as a keynote for RailsConf 2019, and read it aloud there. But it seemed like a good time to re-up this sentiment as the open source world is once again discussing the nature of "free labor", "unsustainable structures", and other such topics in relation to a new security vulnerability discovered in log4j.