Do to the nature of our work, we frequently collaborate with non-technical organizations. This is the first part of what we’re calling our “Devil’s Advocate” series, intended to help non-technical people make better technical decisions by presenting the negative side to current tech trends.
Don’t use open source.
Don’t get me wrong, I love open source. I use open source projects and I contribute fixes back to them whenever I can. Open source is great.
But open source does not make solutions instantly better, more democratic, or more transparent. A lot of organizations– particularly nonprofits– insist upon open source because the philosophy of the open source movement matches their own ideals. Well, that’s nice, but technical decisions should be made based on technical arguments. Open source is the right solution when there’s an open source project that fits what you want to build.
Far too often nontechnical managers ask the dev team to take an open source project and completely alter the functionality without realizing that it’s harder and takes more time to do that than it would have to build something custom. The manager thinks using open source should make the project cheaper and speed up turn around time, if that doesn’t happen he gets frustrated by the work ethic of the programmers. “Why isn’t this done already?” he might ask. “The open source project works out of the box, all you need to do is just make these tiny changes.”
Granted there are considerable advantages to going with an open source solution. It is easier to onboard new devs. You benefit from an established community of devs without having to pay them. You have a mature, fully functioning platform to test various ideas on.
But that last advantage is exactly why open source might be the wrong solution for you.
As code “matures” good developers reorganize it to remove duplicate functions and make it easier to maintain. From a nontechnical mindset it is difficult to understand what these periods of “refactoring” (translation: code clean up) are really doing or why they are necessary. Too often nontechnical managers see refactoring as a period where nothing is getting done because the devs were sloppy and have to go back and fix their mistakes! But all devs, even the best in the business, write code that eventually has to be refactored. It’s an important part of how software evolves.
Imagine we had two functions: send_email which takes values from a form, generated a request to the server to send an email … and forward_email which takes values from a form plus values from a database and generated a request to send an email. We wrote send_email before we knew that we would ever want forward_email, but when someone requested the ability to forward emails that sounded like a good idea so we quickly copy and pasted send_email and changed a few things before renaming it forward_email. Now suppose that we realize we have made a mistake writing the code to generate the request. Or maybe we hadn’t made a mistake at all, maybe we upgraded to a new version of something and that required a change. Both send_email and forward_email need to be updated… but if we had created a third more generic function (say generate_mail_request) and moved the code that wrote the request out of send_email and forward_email, then we would only need to change generate_mail_request.
This is the concept of “abstraction”, building reusable bits of code that several parts of the application will use to do the same thing.
The process of minimizing and reusing code is essential to project growth. However, it can also make changing small things more difficult if the change conflicts with the way the program was designed to behave. This is why taking an open source piece of software and making “a few changes” may in fact take longer and be more difficult than writing the same software from scratch. If the open source project is mature enough it has probably been refactored a few times, creating several layers of code that effect hundreds of features and functions.
Assessing the Ease of Your Desired Change
At the same time most mature open source projects do in fact assume you will want to change things around a bit. Their programmers work in pathways where certain changes can be made quite easily. The trick is understanding whether the customizations you want fit into that system or not.
As a general rule it is usually possible to change the way an open source project looks. If the project has a templating system, there should be an easy way to override the default templates with your own.
For mature and complex projects it is also usually possible to add new, independent features pretty easily. Since these tasks leave the core behaviors alone they only need a place to hook into so the open source application knows it’s there.
Open Source as Parts of a Whole
Now that you’ve heard all the consequences of picking an open source project over a custom solution, there’s good news: the best projects use both custom solutions AND open source. There’s an open source solution for practically every major feature you need, designed to slide easily into place with all kinds of different applications. So if you truly need something unique and there’s no open source platform that fits the bill. You can hire a developer to build something custom, but fill it with open source parts so that you’re not wasting time and money building things that someone else has already built. Pop in a login system, image uploading, commenting … all areas where there are several good open source options available.
And when you’ve finished your custom piece of software … you should definitely open source it 🙂