The boss of it all

The recent Ruby Central tragedy has me in shambles, honestly. It cuts deep at the very spot where I am feeling the most insecurity and the most disenfranchisement.

The crux of the issue is creative control. Writing software is a creative endeavor, and we are just now barely getting to the understanding that even though free software promises open source, it does not promise open governance or shared ownership. Something made by a person is their creation, and in the world of pervasive corporate grift and endless growth-at-any-cost it remains one of the few, and - to my view - purest - forms of being attached to what you produce. Having creative control and exercising it is the ultimate form of caring - something that has become a dangerous trait in today’s software organizations.

I’ve bumped into Abdelkader Boudih a couple of times online, and - frankly - was somewhat put off because I don’t like it when people become rude towards me - personally - too soon. You may have a heated debate with me and we can call each other names, but we have to share a dram of liquor first. But also - because I am biased against “rude by default” as it is something I grew up in.

Man, all I can say - I owe you an apology.

The directors of it all

That said, his initial writeup on the Ruby Central governance mentioning a string of Director-level positions on LinkedIn, nearly had me in tears. I don’t have nearly the amount of vitriol to dispense, and I don’t know Marty personally, and I can’t talk about this in the same words. But I know exactly the type he is writing about, and I know exactly where the bitterness comes from. For I tasted that poison.

It is the ink in the water. The seemingly kind, thoughtful person in meetings who seems never edgy, never speaking ahead. Always a good listener, a good ear for gossip, and talented at “stakeholder management”.

It is also the person that builds glass ceilings above you. The “you are not quite ready for this role” person. The “team X has been having difficulties with your stance” person. And it has little to do with bureaucracy - not quite. In our profession, folks like this are great at executing managerial capture, and - at the same time - the guardians of the very system which makes most software scale-ups a toxic environment.

And - and I’ve seen it first hand too (and had to be in that role) - the person who takes root access away from all the “undesirables” in the moment of crisis.

And I don’t want to pretend I am not jealous here either - I know perception management but I haven’t mastered it.

How much fear can we handle?

We don’t talk about this, but we know exactly what is implied. And, sometimes, I feel compelled to be the person who does talk about it. You may not want to hire Abdelkader because he writes about this, and you may not want to hire me – because I talk about it. It doesn’t matter, because there is a modicum of sincerity and professional integrity that is fundamental to what we do - we create and build and we work in a trade.

I believe strongly that effective leadership in our field requires hands-on experience with the work being managed. A person who doesn’t understand the trade has no business leading teams of practitioners. And I’ve seen this principle play out in practice. Moreover - I believe that you have to consistently build together with those you lead, until such time that it becomes impossible from the scheduling perspective (or your org grows too large to sustain it).

This isn’t just theoretical for me – I’m convinced that the combination of hands-on technical work and management brings the most success to small and medium-size organizations. So strongly, in fact, that this is exactly what I offer: technical leadership that stays grounded in the craft. Because I’ve been in both trenches.

And I’ve seen things play out with “the directors of it all”.

A manager escalates a senior developer to HR over unfounded concerns about workplace conduct. The manager was previously brought in by that very developer to help with stakeholder management that had become challenging. The developer has quit in the end, because the concerns turned out to be false yet had them utterly belittled. It is not clear whether this was necessary if they wanted the developer to quit - it was clear that the developer would have quit of their own accord if asked to.

A director weighing in on a job candidate saying that “I’ve read their blog, and I doubt they will be a good fit for the team”. The blog contained articles with just some opinions on how teams in high-performing organizations should be run. From the very British position of that director, even daring to open your mouth on that issue was a sufficient background for rejecting the candidate. Of course they were not the hiring manager on the team the person interviewed for. Of course they got their way.

As much as I don’t like the divisive bitterness, the way Abdelkader has put it is absolutely, completely on point:

Six months of advising, then boom—he’s running the place. Classic management coup: get close as an “advisor,” then execute the takeover.

One of the best satire pieces on the topic is Direktøren for det hele - a movie about a fake CEO of an informatics company installed to facilitate the acquisition of the company by a competitor.

You can get paid but just for the work you do for me

And - coincidentally - it is exactly where I am struggling the most. One of the underlying narratives in the Bundler schism is that André was trying to make good money from maintaining Bundler. Not “just” money - good money.

By contrast, DHH’s position has always been that open source software is a gift and is supposed to be transacted as such. Coupled to that is a long known policy of 37Signals/Basecamp of not allowing moonlighting. David’s answers on Omarchy are even more telling. Of course you can treat all the maintainership work as a gift if you have the optionality to do so:

I don’t need revenue. I’m already rich.

And make no mistake - I get jealous AF reading this. And so do many others. I would also love to look at things this way. I would also love to be a co-owner of a business to such an extent that I would put my own OSS creation whole-heartedly under the Github organisation of the business and know it won’t be “sunset”, taken away from me or abandoned. Or that one-or-another “director of it all” won’t put an unenforceable license on it, or that a team of appointed designers is suddenly going to impose their design tokens system on the UI of it.

They giveth, they taketh away

Without going into much detail, let’s just say that so far my experience has been the opposite. The impact was significant enough that I am now cautious about placing any open source projects I create under any organization that I don’t directly control. To put things in perspective, at one company alone my legacy consists of 30+ libraries. Some of those were built by my colleagues, but the majority - mostly by me. I no longer have the ability to maintain, expand, improve or derive benefit from any of them.

All by organizational decisions made by leadership, with impressive professional profiles. They have built careers out of a range of achievements - one of which has, as it turns out, been “sunsetting” the work of builders like me.

Neither can I fork them except under a very restrictive set of provisions - because another organizational decision adopted a problematic license company-wide.

That remains a significant disappointment.

Competition is for losers

So it’s little wonder that the party line of Ruby Central sponsorship was to start seeing Spinel as a thread. How dare those people try to make money off of something that is supposed to be a gift, especially since they have refused to partake in the fruits of the Basecamp success? It was their choice, after all: stay with the leader, work the great salaried position (and - don’t get me wrong - 37Signals offers an amazing package, especially if you are not in the US) - and deliver OSS as a gift in perpetuity. Or hold a great position at the little green bag company and exercise stewardship over the parts of Rails which are not exclusive 37Signals terrain. And be happy about it.

This cuts deep into the modern irony of entrepreneurship. Daniel Priestley is frequently appearing on various UK podcasts boasting about “enabling entrepreneurship” and the virtues of succeeding independently. Only there is a flipside to this, which entrepreneurs are not so fond of discussing: they know what they are paying for, and they - naturally, by laws of simple economics - want to get as much of it as possible

When you build for them, the value is your time, your ideas and the products of your labor. It is not quite straightforward to “be an entrepreneur” if you want to do something by yourself, because any move you make can be seen as competitive against your employer. Should you decide to take risks, they should be all your risks. Quit your job (no severance, of course), live out of a hotel in Vietnam and try to make it – just don’t dare to try it while you are still on our payroll.

And if you are producing something that is given for free - make no mistake, we can take it away from you by a vote of the board, and there will be a battery of Directors of It All ready to action the decision.

We want all of your time, all of the time

Same for time. Time is non-replenishable, and the pay usually is for 40 hours (at least in these parts of the world). But that’s not enough for a true entrepreneur - they want to own the hours they don’t pay for as well - even though those hours are not in the contract. Having the builder control what they produce - even as a gift - is not a part of the deal, and pray the deal won’t get altered any further.

So - yes, “everyone can be an entrepreneur” but “not as long as that everyone is getting any kind of money from me.” It is very tempting to say this has to do with “loyalty and retention”, but - once in a truly bitter mood - we know that it could as well be called differently.

The issue with that setup is that it effectively narrows the open paths into just a few possible branches:

• Become one of the “directors of it all”. Have a good LinkedIn. Befriend the right people and make everyone understand that you are not a problem, and that you know how the game gets played. Play the game, nod in agreement, rest+vest.
• Become a principal engineer and figure out what craft occupation is still available as a hobby, without it encroaching on your “no conflict of interest” clauses. Make sure to pick the right big company for the act.
• Go fully indie, start your own business, do whatever you like. Preferably somewhere where health insurance is affordable and there is still social housing to go about.

Any kind of combo arrangement, or arrangement where software can produce value even though it is not under a corporate purview, clashes with the desire of the current tech employers to get maximum return on their talent investment - and with their innate, primordial fear of competition. The only exception is likely the gig economy, where market equilibrium will assure the minimum viable compensation automatically.

Which brings us back to the control angle.

You make it and you should own it

The tragedy of open source anno 2025 is that it has empowered the takers but disenfranchised the givers. Creating a gift is not enough. You also have to be employed by the right party. You have to be good at marketing. You have to have other sources of income - and you have to be smart enough to not say anything stupid. And don’t you dare to try and live off of it.

I hope this situation will change in our lifetime and we can yet live off of software we create without selling the company to Microsoft or IBM and have not only the joy of gifting, but something more tangible.

The weight of creation

There is something profound about the moment when code first compiles, when a library you wrote becomes the foundation for someone else’s dream. Yet we have allowed this act to be commodified, stripped of meaning, reduced to lines of code that can be taken away by corporate decree.

This is the great lie of our time: that generosity must come with surrender, that the gift of code must be accompanied by the gift of control. Control is a double-edged sword—whether it’s a politically motivated moderation team or a corporate boss, both are eager to take it from the maker, each in the name of their own agenda.

But here is the truth: you made it, therefore you should own it. The libraries you create should remain under your care, your vision, your judgment of what serves the community best.

The entrepreneurs who have built empires on open source must learn to loosen their grip. The corporate open-source model has failed for most – it has created a landscape where the most valuable contributions are made by those who can least afford to make them.

We need a new covenant: one where maintainers and authors retain the right to shape their creations, not because they are selfish, but because they understand them best.

Own what you create. Not because you are greedy, but because you are responsible. The future of open source lies in the hands of those who actually build, not the “directors of it all.”

There is no barrier to building, and the only way to overcome bitterness is to create something great. Let’s strive for that.