When I started out as a web developer, I had no idea what open source software was. I used it, I didn't know I used it. I logged into Linux servers with PuTTy (yes, I was a Windows user), I used an open-source text editor, and so on. I was just consuming it, I didn't really get what it was. I just thought "this is great, AND free!"
Years later I got a job at a company called Rareface as the Head of Development. I'd come from a long line of Windows-based agency jobs, writing closed-source software in Microsoft development environments, or using proprietary CMS like SharePoint to deliver content.
Rareface were having a hard time. They'd asked a company in Shoreditch to build them MySpace in a box for £80,000. The company in Shoreditch foolishly agreed, and nobody did the maths. Nobody asked the fundamental question: If MySpace's platform has had tens of millions of dollars invested in it, how on Earth do we think we're going to build something decent for £80,000?
Of course, you can't. So the inevitable happened. Rareface and the other company started to fall out, I was stuck in the middle, ostensibly 'responsible' for the platform with no influence over the original contract. I spoke with a colleague called Bernard (a damned good programmer), about what to do.
He knew a lot about open-source software. He suggested that while a little company couldn't make a MySpace, the open-source software community could harness the kind of development resource MySpace has in spades.
We looked and reviewed half a dozen open source CMS and, after some debate we chose Drupal (which at the time sold itself as 'community plumbing' - perfect!) It then became my job to go to the senior management and investors of Rareface and convince them to allow me to fire the development company in Shoreditch and re-platform us on to Drupal.
I succeeded.
We let the other guys go. Which was a pity. They simply bit off more than anyone could chew. I hired a freelance Drupal developer called Mark, who was awesome. He taught the team how to work with Drupal, we created a migration plan, we migrated their key properties over, technically things were going great. Financially, not so much, but that's another story.
Mainly, I was seeing the power of open-source software for the first time. It's logical if you think about it. If open-source software gets its governance right, you're talking about people collaboratively writing software, making a living while driving forward a product with far more resources than even the largest technology firm can bring to bear. The potential is enormous. Indeed, not for nothing does most of the Internet run on open-source software.
In Drupal, we found our MySpace in a box. And the equivalent of tens of millions of dollars had been invested in it. It was simply invested in a different way, it was crowd-sourced, paid for by the customers of the people who worked on the project, in time by the volunteers who did it for fun, etc.
Scooby-Doo fade
My appetite whetted, but I was still just a consumer. So how do you cross over from being a passive user of open source software to engaging with it, developing it and making your own contributions?
As an individual, there are loads of ways. You can get involved in documentation or you can help out supporting people new to a system in chat or in support tickets. Most open-source software projects have open forums for help and support and you can join associations to give money, you can attend events, you can tell all your friends about a project to help it gain traction. This all helps.
And that's how I started. I enjoyed the IRC community, I liked showing people how to do things in the Drupal issue queue. In time I started producing patches to code, fixing bugs I saw while using Drupal modules and giving my fixes back.
Most people nod sagely at this point, most people kind of get why giving back in this way would help. But let's introduce another scenario. I want Drupal to do something it's never done before, so I write a new module to achieve that. And…
I give it away for free
I'm sorry, wut?!
I still knew some Microsoft guys and they all thought I was nuts. "Why would you do that? Why wouldn't you sell it, charge a download fee?"
And so we arrive at the nitty-gritty.
Open-source software developers write better code
Open-source software developers will give you all kinds of reasons why you should give away your code: it's the right thing to do for supporting education and developing economies; if you share your code others will use it, improve it and give you back the improvements; it's just another business model, you're paid for consultancy rather than a product, and everybody wins; it's more secure because everyone can see the code and warn you of issues; the open-source model reduces business risk, as you can't be held to ransom; etc.
This is all true. But there's another huge reason why I continue to push Code Enigma to open-source its software, wherever feasible. It all comes down to technical debt.
So what is technical debt?
A person with a paper bag on their head with a sad face drawn on it
A simplistic explanation would be every time a developer does something quickly, rather than properly (and there may be reasons for this; I'm not implying a developer who does that is bad, it's often commercially driven) they introduce a debt that needs to be paid back later. At some point in the future that code they wrote, which they know to be bad but which was required to hit a deadline, needs to be done the right way. We've all been there. That's technical debt.
When you write software for a company that will never see the light of day, there's often little pressure to not make short-term decisions. If you know it'll never be scrutinised, if you know it'll never be used again, there's less pressure to do it properly. There's less pressure to document it or be careful about code style.
The moment that software is going to be public, all that changes. Let me give you an example of the kinds of things we had to fix, the technical debt we had to deal with when we decided to open-source our continuous integration scripts.(This is pseudo-code).
Our CI scripts are for deploying applications built by our developers to the servers automatically, so developers don't spend time releasing. We deploy code in the same way for all our customers, but then one day a big customer, let's call them ACME, wants something different. When our scripts were the closed source, this is the sort of thing that used to happen if we were in a hurry, which we often were:
if "acme" in repo: // do some special stuff else: // do the usual stuff
And that is technical debt! We can't leave it like that. What if ACME changes their mind? We have to go back through the code and remove that statement. What if someone else wants to do the same thing ACME does? Worse, what if someone wants to do another different thing at the same point?
Also, when we open-sourced our CI we could hardly leave ACME's name in the code! So things like that became more like this:
// our client might want to do some special stuff
if special_stuff:
run("./my_special_script.py")
Now any customer who wants to do something special can include a 'my_special_script' script in their repository. This is, of course, a very simplistic example, but you get the idea.
Sure, you can have code review procedures, merge requests, and so on. You can achieve this sort of rigour around technical debt without open-sourcing your software. But staff and management change, there may be business pressure to ignore the procedures in place at any given moment, there are all sorts of reasons why an organisation might choose to live with that kind of technical debt.
My point is if your code is open source, you simply cannot ignore it.
And there's more
Open-sourcing our software makes us better developers because we have to think about it. We have to be deliberate and thoughtful by default when we're planning and writing code, because we intend to make it public.
It also makes us better remote workers, which is important for us, being a proudly 100% remote working company. Open-sourcing everything we do makes our developers automatically familiar with the tools required to work collaboratively over distance. It equips us to direct online conversations, accept input from others, accept writing documentation as a normal thing you just do, work on multiple streams without tripping up, develop stronger workflows, which all make us better at work too.
We also get 'free' code review from people who use our code so we get extra eyes on our work. Different perspectives, other ideas, efficiencies we hadn't thought of, etc.
I assert: open source developers write better code.
They might not even be better developers, but they are 'freed' from the short-termism that inevitably creeps into any closed source code, however good the intentions are of those involved, and they are exposed to a world of ideas and techniques that can only improve them.
So my advice to other companies out there in our sector is this:
If your software is good enough to open source, do it. If it isn't, you should figure out what you'd have to do to make it open-source, because that'll be all your technical debt. And if it is open source, you should always be using it.
That's the 'eat your own dog food' part, why would you open-source and maintain something you wouldn't use yourself?
The TL;DR
Every company should open source as much software as it can. You will write better software automatically. There are plenty of companies that already get this, here are some examples we admire.