Open source projects has always been a big bug-a-boo for me. There are clearly a massive amount of Open Source projects for almost any need available. And, a good deal of those projects can be quite helpful to get a larger project up and running more quickly…..however…I have some very strong opinions why dependence on Open Source in the long run can be a case of diminishing returns. Let me “‘splain”.
In no particular order, here are some issues that I believe must be considered, especially for larger, complex projects:
- Learning curve – unless you’re the type of manager that is comfortable just relying on code written by others, your engineers will likely have to at least study the provided code carefully. In most cases, Open Source projects are rarely documented really well. This will require you to be extra careful that the code does not have hidden conflicts with your project.
- Technical support – here you will likely be on your own. While some developers or their community will try to help, keep in mind that the help you get, if any, might not be accurate!
- Interoperability – There’s a big word for you, but it is a critical issue for even the most competent team. In cases where you might depend on a bunch of different Open Source projects, I can almost guarantee that your team will be forced to spend an enormous amount of time integrating all the “interfaces” where your project will have to interact with the Open Source pieces. It can be extremely difficult to locate what might be subtle issues caused by some Open Source projects. The last thing you want to do is waste time debugging issues that are caused by the integration of your code with 3rd party code.
- Versioning – since Open Source code is just that, “OPEN.” This means that you need to be careful which version and/or branch of an Open Source project you use. And going forward, you will be forced to be extraordinarily careful when you need to use a later version of a project you’ve relied on.
- “Dead” projects – you must pay real attention to how long ago an Open Source project was created, and if it is actively being worked on. While Open Source authors genuinely start with the best of intentions, frequently the original developers will move on to new jobs and totally abandon work on something you’ve relied on.
- Security issues – in today’s world of hackers and those who try to steal valuable information, I’d be shocked if a majority of Open Source code will pass the security requirements of your projects. Especially if your project is subject to governmental, foreign, or other security regulations.
- Free versions may not be free – two points here: first, carefully study the license offered by the Open Source developers and that your use will be compliant; and second, since not all Open Source developers are purely philanthropic, it is possible that the “free” version is somewhat limited and you actually need to pay for the “Pro” version that has features that could be meaningful to you. And, of course, that “Pro” version will be the one that the authors will concentrate their quality into.
- Bugs – sure, “bug” is a dirty word. However, let’s be realistic here. Your team will likely have their hands full tracking down and fixing their own mistakes. Do you really want to have your staff spend their valuable time tracking down errors in software that you didn’t write? And, users of your software could care less if a bug is caused by your developers or Open Source developers. You will have to look into issues with both in-house and 3rd party code.
- Bloat – while you may find Open Source code that has exactly what you need and no more. However, sometimes Open Source code will have more features than you need which can make your final product be larger and more complex than it needs to be.
Despite the issues I’ve brought up, I’m not 100% against using Open Source projects. However, I strongly recommend not to heavily depend on a large number of Open Source code in larger projects. “Buyer Beware”! You might, for example, use Open Source projects to get up and running quickly. And then, replace the Open Source projects with your own code that only has the features you need.