What are the good reasons for my company to offer open source code?

Question

I've been thinking for some time now for my company to share code publicly that we use in our projects. Code that is not related to any particular business case, but is useful and often copied from a project to another.

The thing is that when I first suggested this, I've been told that we would be "giving away" our time and money to the competition instead. I'm not a fan of this mindset, but I can see that it is not entirely wrong either.

Some reasons I can imagine for open-sourcing some utilities we are using are:

• We will be able to share code in an easier way.
• We get the chance of it being reviewed and maybe improved by others.
• "The world is moving to open-source."
• Most of our time is actually spend adapting solutions to customers' needs. Custom code build for specifically for a customer is out of question and wouldn't be published.
• The last thing I can imagine is how it would look good for the company to have an organisation with code in it. I mean, as a developer it would make me recognise the company more. It would be perceived as a good company, at least.
• It doesn't really matter if the code is given away for free if the people copying and using it don't know how or when to use it.

Answer 1

Making your code open source is not always a good solution. It is completely understandable if your company doesn't want to do that. For example:

• There are legal considerations. Which license do you use? Under what conditions will you accept contributions, e.g. will you require a contributor license agreement so that the company retains exclusive copyright over the project?

• Maintaining projects takes time. Who will handle issues and pull requests?

• You will have to audit the code first. Are you sure you don't have any confidential details in the code or in the Git history? Note that names, email addresses, and timestamps in commit messages may also be sensitive.

• If the code is used as part of a publicly reachable service: are you confident that this code is reasonably secure, so that access to the source code cannot be used to craft targeted attacks? E.g. having access to source code can be quite handy when constructing a shell injection attack.

All of that is a cost that your company has to bear, so there have to be some benefits that outweigh it. These benefits are often indirect or abstract.

• Open source projects can be a vehicle for PR (sometimes euphemized as developer relations). These projects show how cool and transparent your organization is – with the implication that you also have great products or services to offer.

• Along the same lines, open source projects can make your company more interesting for potential hires. If I were considering to apply to your company, seeing some open-source projects would be a good sign. I could also look at your code to see what kind of problems you are solving, and whether the code looks reasonable.

• It might be satisfying for employees to contribute to some open source project during their work hours.

• If you offer some kind of web API or service, open source projects with related tools or language bindings make it a lot easier to use that API, and can therefore make your product more successful.

Of course, open source projects can also backfire. If the code is unusable, unmaintained, and unreadable, they do not paint the company in a flattering light.

Most open-source projects are not used by anyone else, e.g. because they don't solve problems other people are having, they are not flexible enough, or they are simply not known to other people. So you shouldn't expect that suddenly an army of open-source developers will start fixing your problems for free.

It is also unlikely that you are helping your competitors. If I were competing with you, I'd think twice before starting to depend on tools that you maintain. That's just a lot of risk. But maybe your project is so useful that I want to use it anyway? Then congratulations:

• You have published something actually useful, which is already better than most open source projects.
• If your project is so great, many people might use it – thus realizing the benefits such as increased company reputation.
• You have demonstrated the capability to innovate. Being able to solve new problems is more important than knowing which code to copy.

In the end, the potential benefits of open-sourcing software are often rather vague, and are not worth the effort (have a negative ROI). Unless there's buy-in from management, this is just not going to happen. And you're not likely to get buy-in from management unless you can show how open-sourcing that code makes the company more money than using that time to work on a client project…

Answer 2

You won't win this argument because people think there is more value in the sourcecode than there really is.

They assume... - that because they paid you a lot of money to create it, others can run off with the finished product, as if it were a television set; - it demands maintenance (I don't see how you could be forced to do so); - if the code was written poorly, it will make them look bad.

Give them this example and leave it at that:

A chef at a restaurant (pick a particular example if you can) shares his techniques, dishes and even receipies on youtube or the internet. Does this make you skip the restaurant and copy the dish at home? Or are you drawn to the restaurant because of the quality of the chef?

Answer 3

I have proposed exactly the same in the company I work for. I specifically listed non-business-critical code in the request. I failed. The justification they gave was that if the project becomes successful, people may start demanding new features and that may end up taking too much time. I felt there was something else they didn't want to tell, and there probably was: it is not in the interest of the company to improve my job market value (I'm the one who created most of the code in the project). The reason of people demanding new features is a non-issue, as there is no contract or promise to offer any kind of support whatsoever.

I ended up choosing to create my own open source projects in my own time, unrelated to what the company I work for does. When doing so, the thing to consider is does it compete with your employer. If it does, you may end up losing your job due to competing with your employer in your free time, so choose carefully the open source projects you start and work for. For example, if your employer does Python based web development, and you like Java as well, now would be a good time to create a web development utility library in Java and to place it into Github. Or who knows, perhaps you like low-level development in C. If so, you could do some high-performance low-level programming in C. That surely won't compete with Python based web development!

When deciding your free-time open source activities, you need to consider whether you tell your employer about them or even ask for a permission prior to taking part in that activity. I decided I won't, because the response I got about releasing some of our code as open source was so negative as was the response I got about taking part in a particular open source project, including a warning not to take part in any open source projects that might complete with my employer. Of course, there's a fair possibility they will find the projects with Google. If they do, I already have a justification why my projects won't compete with my employer. I also can specifically for every single open source activity they have specifically forbidden me from taking part in, that this project doesn't have that activity at all. I know I'm a very good programmer, so it is extraordinarily unlikely I would get fired because of non-competing unrelated open source activity.

Whatever you do, don't ask your employer generally whether you are allowed to take part in open source activities in your free time if there's even a slight possibility their opinion is "no". Instead, you can feel the attitudes by asking about a specific non-important open source project. If their answer is "no", then you just won't take part in that open source project (and will start your own project instead, or take part in another important open source project, the one you have always wanted to work for).

The reason to provide open source for you is that everything you do in a private company that is mentioned in your CV will be treated with suspicion (did you really do that? you can't show the code!) but if you have code in Github, people will believe you wrote that code. So, open source is extremely important for programmers wanting to advance their career. You don't want to miss that opportunity!

The company you're working for has a different interest. Their interest is to keep you as an employer for a long amount of time with a low salary. Your interest is to increase your apparent job market value, the company's interest is to make the apparent value as low as possible so that you won't have many alternatives.

And needless to say, you are not allowed to publish copyrighted code as open source in Github (unless it's already open source). Similarly, you are not allowed to use the trade secrets of your employer in open source. Also, the timestamps of your open source contributions should be not in your regular working hours, showing this is a free-time activity and that you're not using your employer's time for your own purposes.

So, instead of providing an answer to what you asked (what are the good reasons to offer open source code?) I have answered a question what you should have asked (what are the reasons to not offer open source code?) and that's a fairly big honking reason:

• Your employer wants your apparent job market value to be as low as possible for the duration you work for them.

Answer 4

Something I learned from the FOSS-Backstage 2018 in Berlin is this:

Open source projects can have a governance process which

• makes decisions transparent and
• includes new-comers. (Two among other)

This is something valuable to have in the company, too. Developing open source software can bring this knowledge into the company.

At the conference they also talked about "Inner Source" which I understood means having the open source processes inside a company. Having developers inside a company working in open source manner, makes them more familiar to contribute to open source projects, too - which is what we would like to have and the company probably also, if they like to have their needs fulfilled by open source software they use.

In the talk she also mentioned Apache and how it was created. The developers had to be convinced that by making the pie greater, there would be more in it for all. That is also the case for the company and cannot be measured as competitive advantage.

Here is an example from my life where making the pie bigger worked: We put a shelf on the playground and some toys inside. After a month we added some more again. After a year, the shelf is too small for the toys all people, not even those having children, put there. There are even toys I would not buy because they are too expensive. Now, every child has more toys than they could call their own when they come there.

I think, this metaphor works great for open source projects. For me, it is about having access to the resources to strive (richness) and letting go of greed and distrust: Putting in one shovel (OS-Project) where it does not hurt and seeing that the others also contribute so you have 10 shovels at hand.