Introduction
Open source software on company time

Open source software on company time

open source software
Most developers love open source software, and often we come across a piece of software that we’re writing and think “it would be great if that already existed as an open source package”, but then, it doesn’t. Since we’re writing software for a company, the natural tendency is then to implement it in-house. The thing is, if you had that thought, chances are someone else might have had the same thought. So, why shouldn’t we open source it? From a business perspective, telling your boss you want to write open source software on company might not make much sense to him. After all, he’s paying you to write software for everyone. If you argument is going to be “open source is cool”, you probably won’t get very far.

Apart from being cool, developing open source software as a company actually has a lot of benefits.

Before I iterate over what I think the advantages are, I want to make one thing clear. When we write open source software on company time, we don’t want to open source the company’s unique selling point. It’d be foolish to think any company would allow that. When I talk about open sourcing company software, I’m talking about general purpose software. Software you need to develop to support your domain. This could be an interface to a database, some utility functions you often use or any other piece that could be usable outside of the context of your company.

Open source software advantages

Quality

Open source software is, by its nature, public. That means that any hack you implement, any security mistakes will be visible for everybody. Therefor, when you’re working on something public, it’s natural to be a lot more cautious about how you develop. But that’s only one way open source improves  quality.

Another reason quality improves is that it forces you to decouple it from your domain. In in-house software it often becomes tempting to include domain logic inside external libraries, because it’s just easier, faster. In the long run, you will have less separation of concerns which affects maintainability. Writing general purpose open source software, forces you to decouple it.

Testing

If your project is popular, a community will form around it. Once you have a community, they will start using it and possibly discover bugs before you run into them. If you have an active community they might even create a pull request to solve the bug for you. That’s free testing and bug fixing for the company.

New features / scenarios

Similar to the scenario with bug detection and public testing, it’s possible someone runs into a use case that the current software doesn’t handle. If they really need it, they might decide to implement it and create a pull request.

Exposure

If your software is of a high quality, it will start becoming popular. Being open source doesn’t mean it needs to be white-labeled. So, every time someone gets in contact with the software, your company’s logo will be there. This gives exposure of your company’s name to a potential large audience of developers.

There are plenty of examples of tech companies that are open sourcing software, to name a few:

If you go through the list, you’ll see they’re not open sourcing their main selling point, but parts that orthogonal to their business model (ie: you won’t see Google open sourcing their search algorithm, or Facebook’s timeline rules). The above is also a list of companies that are *hot *among developers. A lot of developers want to work in these companies, precisely because of their openness. Having exposure of your company to developers could attract new talent. That’s not to say that this is the ultimate hiring strategy, but it’s another channel which could yield some interesting results.

Developer satisfaction

Good developers are, in my opinion, passionate about their work. They will feel happier if they can work on something that solves more than the daily problems they’re running into. Having a happier development team aids in productivity, retaining talent and general atmosphere in the company. Working on something which is open source and not “just” for the company might also trigger them to spend some hobby time on it which again is free work for the company.

Developer involvement

Sometimes developers move on from the company. One of the first things you do, is remove their access to the code repository. Even if they feel they did something useful and want to continue using it, they’ll have to work on it privately on a copy they have. Technically they’re not allowed to, but that’s not the reality.

On the other hand, if the code is open source, and they move on, they can still contribute to it. Likely they will use it in the next company they’re at. This will minimize the loss of knowledge in the team and again get more development time on the software for free. This is something that I experienced first hand when moving on from a company. The software we had written was by no means popular, but I found it to be useful, so I introduced it at my new company. Now we’re happily contributing to it when we need it.

It’s a win-win-win. It’s good for my new company, because they get software that was already developed, it’s good for my old company, because I (and my colleagues) are adding new features and bug fixes for their software and it’s good for me, because I didn’t have to do it all over again.

Conclusion

A lot of the above advantages are only real if your software becomes popular. But what do you have to lose? If it doesn’t become popular it’s just the same as developing it in-house which was the starting point.

Another argument, although not very tangible, is that it’s just the right thing to do. We live in a world where we can only achieve what we’re achieving by standing on the shoulders of others. I’m sure 99,99% of closed source software is using open source software somewhere, so why not be a good citizen and contribute back to the community?

Kenneth Truyers
View Comments
Next Post

Git as a NoSql database

Previous Post

Avoiding code ownership