Open Source as a business owner
The totally rational business case for contributing time and money to open source.
There’s a free rider problem in open source. Right?
Companies… sorry, not companies, megacorps build multi-billion dollar business on the efforts of free software, and don’t give back a dime.
I’ve talked about this at length. It’s not really my topic today. It’s the story, though, the backdrop.
We’re not the megacorps. When we say, You’re not Google, we’re normally talking about adopting engineering or deployment practices that are inappropriate for our scale. I want to talk today, though, about why we might not (i.e., shouldn’t) mimic their approach to open source either.
I can’t speak to the economics of the Microsofts, Oracles, Facebooks, and Amazons of the world but, for small to medium-sized enterprises, actively engaging with and supporting open source is nothing short of smart business.
It’s both an easy source of competitive advantage1 and a direct line to the best talent in the market — talent which is otherwise essentially unreachable. As such, engagement with open-source boosts business continuity like almost nothing else. I’ll go as far as to say that it’s among the highest ROI activities that a software-powered SME has available: a small investment over time pays massive dividends. It’s liking flossing for business2.
So that’s the topic today. Let’s go!
§
There’s a certain kind of studied economics and then did an MBA (Homo economicus as a role-model) attitude that sees a free rider problem as a moral imperative not to pay.
Haha! Look at how clever I am, taking this for free!
There are all sorts that we could say about this. Structurally, it seems analogous to…
Haha! They have an honesty box, but why would I put money in that?
… but, even on its own terms, not paying for a good because it’s non-excludable fails to demonstrate any degree of higher-level rationality.
We know that free-riding leads to the destruction of the good being consumed, via the tragedy of the commons. If that good is the software that we’ve chosen to build our business upon, then (by our own lights) our business model had better be structured around a quick exit. We can’t be building for the long-haul. As Jimi Hendrix had it:
And so castles made of sand slip into the sea, eventually…
Sure, you can use open source without paying for that. But that’s like saying you can drive without insurance. Or — to give an example for the Finance Bros — you can be a trader that doesn’t hedge. There might be some mythical career defining unhedged trade… maybe… but to not hedge as a matter of policy? That’s madness.
So too with your software dependencies. These are the foundations of your business. If they crumble, you don’t have one.
Or you have the highest-risk, highest-cost rewrite into whatever the replacement is. Until that one crumbles too.
This is no way to run a business, to build an asset.
Now, if you’re Facebook (or the like) you’ve got the resources to bring your dependency in house. You really are Google, so your needs are unique, and you’re going to fork it anyway.
If, though, you’re an SME, you can’t do that. You can’t maintain your main dependencies yourself. Not by yourself. Instead, all you can do is contribute (proportionally to your size) to a collective effort to the projects you depend on healthy. It’s exactly like insurance. You pool the risk collectively so that everyone is covered.
There’s a bootstrapping problem here: if not enough people fund the project, then it will go under despite your contribution, and so that money is wasted. This is one of the reasons why Django is so compelling from a business case perspective. The Django Fellowship Program has now been running for a decade. It has a proven track record of keeping Django sustainable (and sustained). As a business owner, that track record is of massive importance. I know Django will be with me for the lifetime of my project, and that my contributions to it are going directly (and effectively) into making sure that that is the case.
So before we move on, here’s the form to become a DSF corporate member. Go fill that in. Pay your insurance premium. Invest in the sustainability of the framework you chose to build your business upon.
§
When I got into open source, it was absolutely about business continuity. I’d found a niche, building mobile applications with API backends. It was a good time to be able to do both.
For the backends I was using Django, together with the early days of Django REST Framework (DRF), plus django-filter, and for some admin-type stuff, crispy forms and django-compressor. Packages that I’m still involved with to this day.
DRF was my starting point. It was the core of what I was building, and the key point was, I couldn’t have it break on me. It had to keep working. And I had to make sure I could handle any incoming breaking changes before they affected my (clients’) applications. (There aren’t often conscious breaking changes, so this last one is in the main early testing, and then reporting back if something expectedly changes.)
Getting involved in contributing was my way of insuring that the dependencies I’d chosen would continue to be reliable for as long as I needed them. At the bottom level, they already work. The hard bit is done. There’s no realistic problem that can arise that you can’t fix or work around.
In contrast, very realistically, there will be issues that arise that are, for you, urgent. Issues that need, for you, to be fixed now. The trouble is they’re often only urgent for you. If you’re relying on the package maintainers to address your issue, you could be waiting some time. If you’re looking at the source code of one of your major dependencies for more-or-less the first time, and hoping to be able to promptly (reliably) work around a (for you) major issue… — well, good luck, is all I can say.
§
Software is built on abstractions. Hallelujah! But it is part of the lore that those abstractions are leaky. Bugs will arise, and you’ll need to drop down a level to resolve them. You have to be able to operate at the level below your abstractions to practice software engineering reliably.
If you can’t dig into your dependencies — and it’s interesting to think about what that looks like if it’s not contributing to them at least semi-regularly — then sooner or later, and probably sooner, you’re going to hit limits to what you can achieve.
The default use-cases that the framework provides only go so far. Every project of significance will need to go beyond them. It’s the custom bits that add the value. At that point, you have to open up the box and make the changes your project requires. If you have any aspirations of reliably shipping software on time and on budget, you can’t be doing R&D at that point. You have to know what’s going on.
As such, contributing back to your dependencies is the training ground for using them in your daily work. It’s the reps at the gym, the track work, that means you perform on race day. In-depth knowledge of their stack is what separates top teams from everybody else. That knowledge comes only from working on those code bases themselves.
You’re serious about shipping software? Reliably, with quality, on time, on budget? Then you’re involved. Simple as.
§
All of that applies to your senior engineers. Ultimately, they’re the ones that need to know.
The other problem we face as business owners is how on earth do we level up our juniors?
Well, no surprise, it’s the same story.
Open-source code is some of the best code out there. At least for your key dependencies, certainly. It follows best practices, it has CI, testing against multiple versions, it uses linters, has docs builds, decent change notes, and all the rest of it.
You get to work with the best engineers. Your code (your juniors’ code) will get their review. The learning from this immense. You have to use git, and write a proper commit message, and learn the importance of a clean history. What rebasing is, and how it works. And all of it.
Give your engineers a bit of time to contribute back, and not only are you strengthening your stack, you’re strengthening your team. Open source is a skill development playground second to none. Theory is important, but real progression is 99% practice.
You’re improving your dependencies, feeding directly in to the skills you need to deliver your product or service, and bar the time, there was no additional cost involved.
Contrast that to A.N. Other learning platform, that still takes the time, has significant cost, is full of material that doesn’t get to sufficient depth, and is not closely targeted to your real work. Too much reading (or watching) and not enough doing. It’s not going to be of anything like the same amount of benefit. Again, the ROI on open source is incredible.
§
Companies that are involved in open source have a much easier time hiring. Sure, they advertise, they put it out on LinkedIn (if they’re brave). But they’re also at the conferences, where they’re talking to people that they already know from collaborating online. It’s direct connections, direct contacts. To people who you already know are qualified.
Beyond this, though, companies that are involved in open source have access to a whole swath of the best candidates that simply wouldn’t consider a company that wasn’t so involved. The very best bit of the pool isn’t available to you at all if you’re not inputting back.
You sponsor Django. That link again. You’re at the conferences with your team. Members of that team are contributors to Django itself, or maintain packages in the ecosystem. They’re always talking about how your company supports that.
You’re there talking to an experienced contributor who just so happens to be thinking about a change. You literally can’t buy that.
The next day, you’re talking to a talented youngster. They approached you. They are keen to work for your company. Not only that, but they even applied. As you’re talking, you realised they didn’t get through the screening. What a mistake. A mistake you can rectify, but one that you’d never have noticed if it weren’t for that conversation3.
Both these opportunities, and countless like them, come up only because you’re involved with Django, or whatever your tech is. It’s a reputational gain that comes along with the insurance, and learning and mastery benefits that we already talked about.
§
So I think the case for being seriously involved with open source — in my case with Django — is pretty clear.
You’re investing in the sustainability of the technology you built your business upon. You’re developing your team’s mastery of that technology, allowing them to perform better. You’ve got a best-in-class training pathway for juniors, that plays directly into the work that you want them to do day-to-day. And you’re directly connecting to the most qualified pool of talent for your tech.
Any one of those points would be enough. That they feed into, and reenforce, each other only strengthens them.
But note what I didn’t talk about.
I didn’t mention any of the community benefits that always make so much of. I might have said “giving back”, but only in the context of a direct, self-interested benefit to you.
The business case for open source doesn’t need them.
But that doesn’t mean those benefits aren’t real.
They very much are. They’re why most of the old-hands hang around. Again, I’ve talked about this before. The fact that you get all the rational benefits, for doing what you’d want to do anyway, is icing on the cake. 🧁