The Good, the Bad and the Ugly of Enterprise Open Source

This time last month I was at NodeConfEU and was gutted that I had to leave early. But thankfully, all the sessions are available online for my (and your) viewing pleasure. I was looking back over them last week and came across this great discussion on Enterprises, Node.js and open source: the good, the bad and the ugly with Ahmad Nassri (TELUS), Paul Savage (NearForm) and Gordon Suttie (EY).

Ahmed, Paul and Gordon do a great job at recapping the good (benefits) and the bad (challenges) of Open Source in large enterprises, but it was the ugly truth covered in the final part of the conversation that really hit home: there is an onus on all enterprises who use Open Source to start investing back in the community. For those of you who don’t have time to listen to the whole session (though I would recommend it), here are some of my main takeaways from the conversation….

[caption id="attachment_300002353" align="aligncenter" width="2400"]

Paul Savage, Ahmad Nassri & Gordon Suttie: NodeConf EU 2018. Kilkenny, Ireland.[/caption]

Nothing new here – it’s widely accepted now that, like it or not, most enterprises are reliant in some form or another on open source software. The group gave a long list of why Open Source (and in particular, Node.js) has become such a cornerstone in most organisations. It makes developers highly productive and it’s easy to adapt and learn with infinite learning resources available. It’s also cost-efficient, with no mandatory certifications and no costs for the IDE.

Indeed, Ahmed goes as far as to say that if you want to build a modern app, that is the most performant, at the lowest cost, while attracting the best talent into your dev team, you will almost certainly choose Open Source. Commercial software alternatives might exist – but who wouldn’t want to avoid a lengthy procurement process? Particularly if you can get 90%+ of what you need for a modern app off-the-shelf and for free through the Open Source ecosystem.

The arguments for  Open Source are pretty well established, at this stage. What is even more interesting for me is how the conversation soon turned to the challenges of adopting Open Source in large enterprises.

Interestingly, it wasn’t best practice architectures or favourite tech stacks that dominated the conversation but how to approach many of the cultural challenges that come with the success of Open Source, for example, the mental models developers need to build to cope with the constant change in the ecosystem or the challenges in collaborating across silos in development organisations.

I was also struck by the discussion around how success in lean, agile development can lead to the uncovering of gaps in agility across an organisation. For years, IT has been responsible for just getting it working or just keeping it running. Now that some organisations are seeing success in terms of building agile and efficient development and operations teams, it turns out that other parts of enterprises are just not set up to work with an agile software delivery team. They still want to toss a detailed spec over the wall and pray they like what comes out the other end of the development process. If you turbo-charge an engine without making modifications to the rest of the car – the engine will just go out through the front of the car.

My takeaway from this part of the conversation was that if you are building skills for a modern, open, agile software delivery group, you need to think more widely than your technical staff. It’s really important that people from across the whole know how to work in and with an agile development team. Otherwise, you will end up with someone in the business deciding that being agile means you should be able to add 5 new features the day before a major launch.

But for all the benefits enterprises gain from Open Source, the biggest, “ugliest” truth is that many of the enterprises, who get so much for free from the Open Source community, don’t contribute back. This is means we are not optimising the Open Source ecosystem.

There was a time when a large proportion of the people using Open Source were also the ones who were contributing and maintaining the modules. These days, as the use of Open Source is proliferating, the ratio of contributors and maintainers to passive users is decreasing dramatically. This is putting undue pressure on some individuals and introducing risk to the overall sustainability of the ecosystem.

Paul shared a cute scenario (presumably inspired by a real-life story) which illustrates the problem: sometimes a module may be maintained 2 or 3 people who get to know each other very well. Sometimes 2 of them get to know each other so well, they fall in love and get married. So far, so good. A little while down the line, maybe a little bundle of joy arrives. A lovely event in any love story – but a bit of a plot twist for their Open Source project. Anyone who has had a new-born up-turn their lives will know that babies leave very little spare time for voluntary activities like maintaining Open Source modules. The likelihood of any major updates for that module in the following year to 18 months has dramatically now decreased, the risk factor for using the module has increased. The group spoke of some indicators that a module is trustworthy – but there is no risk indicator that can predict such a turn of events.

If a large enterprise does happen to have a dependency on a module like the one in the story above, Ahmed argued that there is both a moral obligation and a professional responsibility for that organisation to help maintain that code. The group then went on to outline some of the main blockers to enterprises addressing this moral and professional responsibility.

It seems the reasons most enterprises don’t participate in the Open Source community fall under two areas: culture and process.

From a cultural perspective, it’s important to educate all parts of the business about the benefits of building the Open Source muscle, to build the sustainable links between the modules that need attention and maintenance and the organisations that are dependent on them.

But making the cultural shift to start participating more fully in the Open Source community also relies on putting the right processes in place. That includes an agile infrastructure that allows for small incremental innovations, rapid deployment, security by design, good governance models. Needless to say, all of these processes don’t just benefit those who want to contribute to Open Source – they are often the goals of any organisation wishing to succeed in this digitally transforming world. This is just one more good reason to accelerate efforts.

Lastly, if all of this resonates with you, remember you’re not alone. We are interested in working with anyone who wants to promote best practice open source (and InnerSource) practices in their organisations. As the NodeConf session made so clear to me, it’s not just about technology – it’s as much about process and people too. Here at NearForm, we can help you with all three . If you want to champion the idea of giving back to the Open Source community and would like to help build the culture and processes that allow large enterprises do that, we’d love you to get in touch !

[embed]https://www.youtube.com/watch?v=0yMJ6cNrK2Q[/embed]