Open source and the ability to modify code

2013-02-28 Nick Larsen

If you google for the advantages of open source software, you will get results that enumerate a few ideas like this:

  1. It's cheaper!
  2. It's more secure!
  3. No vendor lock!
  4. Better quality!
  5. Auditability!
  6. Customizability!
  7. ???
  8. ...

And if you read what they write under customizability, what they mean is that you can modify the code for your own system. Modifying open source software for your own system is highly inadvisable. As soon as you make a change, you have forked the project and forked projects are often difficult or impossible to keep up to date with changes in the master branch.

So open source software is just for using, not for editing?

No, of course not. If you need to make tweaks or other changes to the code of an open source project, you should be contributing your code to those projects, and integrating the new features to your system once your code is merged.

On the Careers 2.0 project I write code for, all of our open source dependencies are maintained through nuget, even the ones Stack Exchange employees have contributor access to. If you want to make a change, submit a pull request, have it accepted, publish the updated nuget package and update the nuget reference in the project. It sounds like a long path, but it keeps your system up to date and makes all of your contributions public.

But what if there is a bug or a critical vulnerability?

There are exactly 1 situations I can think of when it is acceptable to modify an open source project, compile it and deploy it within your system:

  1. You need an immediate fix for a vulnerability that must go live until the fix is merged into the master.

When the project has a vulnerability, I'm not going to argue taking anything but the shortest line approach to fixing it. If it's just a bug, that's just code for no better time to submit a pull request!