Much has been written about open source software and either its threat or virtue to corporations. I've worked for corporates in one way or another for nearly twenty years and have seen nearly a 180-degree change in attitudes, from the famous Steve Ballmer quotation: that linux is a cancer to Microsoft publishing the code of some of their most successful products on Github.
Despite that, I still work with people and companies who are not convinced and who look at open source components with suspicion.
This is my view on why companies publishing their code is good for them - specifically from the companies’ point-of-view.
My code lives on Github
I joined Github in 2012, and since then increasing amounts of my code have lived there, including what I write for myself and much of the code I write for work. Some people might find that surprising, but there are three good things which come from this
- I write better code when people are looking - nobody wants to look foolish in front of their peers. For sure I still make mistakes, but I try harder and do more research.
- My solutions are more general if I think others might use them - even if I’m solving specific problems.
- Security is a first class concern when the code is in public - for example all secrets should be stored in the environment. There are great ideas on how to do this (and more) here: https://12factor.net/config
Some examples:
- My cloud infrastructure as code: https://github.com/richardjkendall/tf-modules
- Keycloak magic link login: https://github.com/richardjkendall/login-with-email
- Command line tool for working with Amazon Athena: https://github.com/richardjkendall/athena-query
- A tool to prototype backend APIs: https://github.com/richardjkendall/reflection
All companies should do this
I consider there are serious benefits which come from these attributes for companies who do their development in the open.
| Item | Description |
|---|---|
| Higher quality code with less defects | Code written in public view and making use of well maintained open source dependencies takes on similar properties to peer reviewed scientific research. It is not guaranteed to be free from errors, but it is likely to be better than code developed in closed systems. |
| More flexibility, lower development costs | The more general solutions will in turn be more flexible. This is good because as your requirements change as a company, these more general solutions are likely to be quicker and cheaper to adapt to those changing needs |
| More secure code, less incidents in production | Publishing your code forces you to think about how you manage your secrets and data. None of this should ever be embedded in your code and this cannot happen when it is pushed to a public git repository. You’ll end up with far less self-made security incidents as a result of these practices |
What about IP?
It may be the case that you have some data or algorithms which represent your Intellectual Property or perhaps you’ve found a way of using a cloud service in a way nobody else has, and this gives you a competitive edge.
If it’s data - then that should not be in a code repository anyway, so my third point above stands.
For algorithms and other bits of code, I’d argue if you’ve worked it out then very likely somebody else has. If you really want to, then keep those bits of code private and abstract them from the rest of your code base as API calls.
At the end of the day, I think by putting our work in the public domain, we all push ourselves forward - and there are plenty of other mechanisms to protect our IP in meaningful ways - for example patents.
-- Richard, Jun 2022