Thinking about open source? Sit down here and take a read.

I’ve been around tech for a long time. I worked at a lot of companies that build software and I have seen lots of trends come and go. I have been using, supporting, and building open source and open-source communities for the better part of 15 years. I am not an expert in open source, because truly no one ever can be – it changes all the time. I do possess a great deal of knowledge and awareness of open source, and how it gets used – or rather misused – in what I would call “corporate open source” projects. This short discussion is focused on that microcosm of open source, and I would recommend anyone considering either using or building open-source software in that model read on.

Just to set expectations, I am not anti-open source. I am very much PRO open source. It has HUGE advantages and benefits that far outstrip conventional closed source if it is applied correctly. If you are a start-up, with a great idea and you are trying to flesh it out, strengthen your user-base, and otherwise grow software capability very quickly, having open-source components or indeed your whole product, can be a huge advantage. If you are an established company and want to increase your exposure and enter an area you have not really done things in before, this is an excellent way to do so when applied correctly.

Unfortunately, “corporate open source” doesn’t have any of these characteristics. At best, it is an attempt to present a face to the world of technological innovation and capability. The “look what we did” effect. At worst it is a poorly thought-out program that conflates the magic of “free developers” and “lots of money” with having open-source tools. The “if you give it away, they will come because, free?” scenario. Thankfully I have witnessed very few of the extremes and most companies land in the middle. The mistakes they make fall into a couple of basic buckets that I will cover here, as something for you to consider in your own open-source journey.

Open Sourcing the wrong things

Companies that make software have all kinds of stuff “lying around” and all manner of new projects that could be open-source candidates. The issue I see primarily is that they tend to open up the wrong things, or at least things with the smallest impact.

If you did not know, corporations, and particularly those that are not pure tech companies, are super risk averse. They see the act of opening up something as a massive risk with no reward. “What if our competition takes it?” “But that’s our IP!” “We won’t make any money off it anymore!” are some of the more popular things I have heard about why things do not get opened up. To be 100% clear, your competition already has your software, no one cares about the IP at the core but you, and if you use open-source projects correctly, and build the right business around them, you will make plenty of money.

Unfortunately, companies continue to pick away at the edges of their products and turn things that are low risk to them, but ultimately extremely low-impact to the wider world into their open-source projects. The very best thing you can open source is something that you are no longer interested in maintaining or developing, but that has an established user base. You get to unload dead-weight to the “community” and the community will love and thank you for it by rabidly preserving that tech for you.

Allowing open source to equal “do whatever you want.”

Every company with a functioning open-source community inside it treats open source as a privilege. That means that you must work to get those projects released, and you need to have a real reason for them to exist in the first place. They are aligned to the goals of the company and the business and are NOT a free-for-all where people show up with whatever passion project or random thing they thought of and release it publicly.

“Open source != do whatever you want” has been a mantra of mine for years. It stems from the fact that meaningful contributions to open-source communities work best coming from well managed and regulated programs of development and release. It is still software, and it should still have some basic guiding principles. Even more so when you are paying your developers full-time to work on it. If they are just randomly working on side projects and widgets, then your open-source program is already in the hole. Process is not the enemy of innovation as so many people think it is. It is the way that your innovation contributes to the larger ecosystem you are part of. For better or worse, in “corporate open source” that is the company that signs your paycheck.

Misaligning policy out of fear

Alongside the “it should matter what you are doing” thought is another that comes from the business side. Contributing time, effort, and most importantly code to open-source projects is how a company shows its commitment to open source. Unfortunately, far too many companies make this either extremely difficult, or outright impossible. There is not a single piece of modern software that does not live and die on the back of an open-source project somewhere in its many lines of code. As a consumer of that open source, it is almost a moral imperative that I give back to it if I am using it.

Again, process should exist, but if I am trying to figure out how many lines of code is too much, or I have to literally register all of those lines in a form somewhere, you do not have a process. You have the makings of open revolt. Process for the sake of process IS the enemy of progress, and if you are trying to figure out how to allow open-source contributions, the answer is simple: ask developers to simply put the name of the project they contributed to in a form. That’s it. One line, name – project name. The end.

Tracking every line of code sounds great to lawyers, but the reality is no one will ever go read that. Ever. You are just creating work that in the end does nothing but discourage a thing you very much want to have happening. The more your developers can contribute to the open source you use and need, the more it benefits you by improving your products alongside it. You should be able to know if someone in your organization is working on a project you would rather they didn’t. That level of basic information does not require a detailed line-by-line though.

Those are the big 3 that I see so commonly misunderstood. There are many others. The “we will make millions” myth, the “we can let others build this for us” fallacy, the “everyone needs this” misguidance, and a personal favorite, “this shows our leadership in open source”. No. It doesn’t. If you are looking at open-source, I would urge you to resolve the contribution issues first, as they will have a much greater impact on your business than creating new software. Open sourcing something doesn’t create less work for you, but improving software your product uses and you take for granted just might.