3 open source myths that might be inhibiting your team’s progress

If you are an effective leader, you are constantly looking for ways to help your team develop.

So when your bright sparks want to learn and use newer, more modern software – you’d like to help with that.

You also anticipate that the team will be able to produce more value and be more efficient. It’s a win-win.

But what if the software is open source?

If it is widely used and well regarded (e.g. the analysts have them in their magic quadrants etc), you feel comfortable, but your tech teams and others may not.

As a leader, your job is to break the barriers down – freeing your team to explore and learn and deliver.


Here are three common open source myths, and how to debunk them:

1. Security – “Open source is not secure”

Although open source code is available to view, does this translate to a higher risk of attack? No:

  • With more developers looking at the code, vulnerabilities are usually identified faster than with proprietary software (and its small developer community)
  • Open source has much lower potential for backdoor risk. If you were looking to program a backdoor into your software – you’d need closed source

2. Skills – “Skills are harder to come by than with the older software that we use”

  • Open source is easy to learn – with broad user communities and many free resources such as blogs, active forums and videos to access
  • It is easier to work out what the software is doing and debug because you can see the code
  • Students prefer the freedom and lower cost – so adoption rates are high
  • This means that the total cost of ownership is potentially lower

3. Quality – “Open source has lower quality code – you get what you pay for”

  • Not really: with large, active communities, errors are identified & rectified quickly
  • The community contributors are typically passionate about their work – free or paid
  • Activities are coordinated centrally, QA teams check community contributions
  • This means that the quality of the code is potentially higher

What other open source adoption barriers are you breaking down for your team?