Why You Need More Than Just Open-Source

by Kamal Brar, Vice President and General Manager of Asia Pacific at Hortonworks

In 2016, the Open Source Drives Digital Innovation study commissioned by Red-Hat and conducted by analyst house Forrester revealed that 52% of CIOs and senior IT decision makers in the Asia-Pacific (APAC) region are already tapping open source software in areas such as cloud, mobility, big data and DevOps.

More IT decision-makers are turning to open source to drive better efficiency and digital innovation, as its flexibility enables organisations to build new customer experiences, services and products more quickly.

As more enterprises tap open source there are some misconceptions about what open-source means. Open source technology allows for incredible collaboration between people, communities and projects. Yet many inadvertently associate the words “free” and “easy” with open source which is not always true. Open source makes tech easily accessible and collaborative, which drives incredibly fast innovation. But open source is much more than easily accessible tech. Enterprise needs must be considered and that is why the business of open source tech is about more than just accessibility.

Here are five reasons why you need more than DIY (Do-It-Yourself) open source:

1. Open Source doesn’t mean it’s all designed to work together.

The open source tech community is not necessarily motivated or inspired to make an integrated set of different open source technologies (projects) work together. Each team is in charge of their own project – but making it all work together, easily, seamlessly – spending time to test and certify different sets of tech together is not their mandate. The community is responsible to their members, and to the guidelines of their community – each of which can have differing rules, different codes of conduct for each project. The community is not responsible to other communities and are not necessarily developing the necessary “glue” to make everything work together for an enterprise grade level of integrated functionality.

Success Requirement: Someone (usually a software vendor) who is a member of the communities, to compile different projects into a single implementable software package.

2. Open Source creates an unprecedented pace of innovation.

The collaboration of open source creates an unprecedented pace of innovation, but this pace is not always compatible with enterprise business. Not every business can implement new systems or upgrade existing ones, create new processes and train people to adapt at the same pace that the community is developing at. And in fact, sometimes such a pace can be detrimental to good business outcomes where some stability is required to refine and develop best practices and outcomes.

Success Requirement: Access to multiple (possibly more mature) versions of the integrated software package to give enterprises the freedom to update to newer versions at their own pace.

3. Open Source is typically focused on the bleeding edge.

Not every enterprise customer needs the leading edge, or the so-called “bleeding edge”. While the open source community continues to shift towards the next version, the newest features, the new release, it still takes time to mobilize an enterprise to adapt to the change. Enterprises may not always be on the same leading edge innovation that the open source community is on. Business critical environments may be based on more mature versions of open source tech for better business stability. Creating a balance of adapting innovative new tech with stable, more mature tech is not necessarily in alignment with the objectives of the open source community.

Success Requirement: Establish a clear new technology introduction path, usually by including an early version of the new tech as a technical preview into the integrated software package.

4. Not all needs naturally create open source communities.

Some requirements – such as enterprise security and governance do not organically manifest themselves in open source communities. Only when there is an application, and integration across different technologies does this become an issue. For some needs to be met in open source, there needs to be a voice representing enterprise needs in a public forum, to foster innovation and collaboration of needs into either new or existing open source communities.

Success Requirement: An enterprise voice in the open source community.

5. The open source community is not responsible for your success.

Open source means collaborative innovation that is easy to access. But easy to access doesn’t mean it’s easy to succeed. For example – almost everyone has access to a grocery store and the raw ingredients it offers. But to make a casserole, a souffle, to create duck au confit requires experience and expertise. The open source community is no more obligated to making enterprises successful with their tech, than a grocery store is obligated to make someone a great chef. To make your project succeed enterprises need expertise; expertise than can be home-grown, hired, and/or trained. In most cases a combination of in-house staff and experts from outside who had done this many times are the best approach. Simply being able to download bits does not result in a successful business outcome.

Success requirement: Connect in house software deployment, integration and testing with outside experience, expertise, enterprise support, professional services and education.

Kamal Brar is Vice President & GM for Asia Pacific/Middle East at Hortonworks. He joined Hortonworks in 2016 to lead the expansion in one of the growing regions for the company. Kamal is an entrepreneurial leader having successfully led some of most successful disruptive technology companies in the world. His experience extends from managing large $125M+ USD businesses with broad range of high value deals, complex solution selling to leading the inception of cutting-edge technology based start-ups across the Asia Pacific region.

This is an article contributed to Young Upstarts and published or republished here with permission. All rights of this work belong to the authors named in the article above.