This is a pre-release chapter from my upcoming book about developer selection and beginning IT projects – I hope you enjoy it.  For more on the book, or notifications about its release date, please send me a quick message via my website.

Bruce is a chef who is famous for his delicious tomato soup. People flock to his restaurant from miles out of town and naturally he keeps the recipe a closely guarded secret, lest another chef cut in on his business. In this respect, we would call Bruce’s recipe “closed source”, meaning that while we can see the end result, we cannot see how it is made.

Later in life, Bruce decides he’s had enough of the restaurant business retires. Without a restaurant to serve it in, Bruce releases his soup recipe so that other chefs may serve it, or people may even make it at home themselves. Bruce has essentially “open sourced” his recipe.

In a similar way, a lot of modern software is now open source, meaning that anybody (usually another developer) can see exactly how the platform was built. This initially seems like a ridiculous idea (if everybody knows Bruce’s recipe, they will make the soup themselves and his sales will plummet). However the issue is not so cut-and-dried and open-source software has some other compelling benefits for its vendors:

• open source software fosters a community of trust and transparency amongst its developers
• other developers (many better than the vendor themselves) will spot and fix bugs and contribute them back to the community
• technically it is possible for somebody to copy and use the software, so the risk of people doing this is real. But if they do so, their version will become incompatible from the ‘base’ version and they will forego any the aforementioned updates or bug-fixes from the community and/or vendor. So this is actually lower-risk than you might initially think

However, open-source software also suffers from a variety of ailments:

• you still need a strong governing body to keep the software updates on track and in a consistent direction for the software’s evolution
• failing that, because the software is contributed to by a wide variety of disparate developers, there is no single accountable entity to address problems when things go wrong
• in-fighting and personal/political differences amongst members of the open-source community have brought many open-source projects to a standstill

To clarify, when talking about open-source here I do not mean that you open source your software product (that will be just for you). Instead I’m talking about the platform that your developer uses to build your software.

The open vs closed debate has very passionate advocates on both sides, but I don’t think it really matters. So here’s my recommendation to you:

• open source is usually free (or at least cheaper), but any money you save is minimal compared to other costs in your business
• open source is touted as having a stronger & more giving community but in my experience there is nothing lacking in any of the ‘paid’ communities. Developers in general are very willing to share their time & expertise, regardless of the platform
• there are other much more important considerations in selecting a platform, like speed and developer support
• most systems use a variety of platforms/languages, so you will probably end up using a bit of both anyway

Ultimately I suggest you simply ignore whether a platform is open- or closed-source and evaluate them on their other merits