Going Full Throttle on Open Source: A Look at Benefits and Challenges

Porsche and POSP

Open-source software (OSS) has undoubtedly gained significant momentum over the past two decades. This week, Porsche, along with its subsidiaries, unveiled its expanded open-source initiative--Porsche Open Source Platform (POSP). This move highlights the ever-growing sentiment among mainstream corporations: software is pivotal for business success.

Over the past decade or so, I've collaborated with businesses, aiding their transition to open-source platforms ranging from databases to big data platforms, developer frameworks, and platforms-as-a-service. Having witnessed varied industries, notably the automotive sector, take the open-source plunge, I've identified distinct advantages and hurdles in wholly committing to an open-source strategy, akin to Porsche's recent declaration.

It's More than Free Software

Going the FOSS (Free and Open Source Software) route isn't just about accessing software for free or sidestepping exorbitant fees to proprietary software vendors. Here's why:

Community Engagement: It allows companies to stay attuned to global developer communities, driving innovation and shaping open-source projects that align with a company's core product strategy.

Attracting Talent: Companies can attract and engage top software engineering talent rather than depend solely on the skills and roadmaps of commercial software vendors.

Customization: With greater control over software components, businesses can fine-tune products for differentiation.

Porsche, in its announcement, elegantly encapsulated their objectives:

Nothing is Free

With all of the potential benefits of a company going full-throttle on open-source adoption come some real challenges. Here, in no particular order, are some of the high-level challenges I've seen companies deal with:

Keeping Up With Rapid Software Release Cycles

Open-source software updates and minor/major releases move MUCH faster than general commercial software releases.  This puts companies on a faster release treadmill than most product/engineering teams are accustomed to. Most enterprises can't metabolize more than 2 major releases a year and struggle just to keep security patches updated. OSS releases come fast and furious in weeks, months and days.  

IP, Project Influence, Continuity

Permissive/Copyleft license structures mean that the benefits of OSS contributions will accrue to potential competitors. 

There's no guarantee that a particular open-source project will thrive. An academic paper in 2019 estimated that 16% of open-source projects are abandoned. Any critical open-source projects underpinning a core platform technology or product that a company builds upon will need to be kept alive to avoid any software supply chain disruptions. Some firms don't want to be in the business of maintaining zombie open-source projects and would rather allocate precious engineering resources to core product features.

Where Does the Buck Stop?

Similarly, there's no guarantee that a critical feature/fix will be incorporated into an important OSS project at all, let alone within a desired timeframe. There's no "one throat to choke" in terms of vendor accountability if something doesn't work, a patch isn't delivered under a certain SLA, etc. Changes/requests shift from leaning on a vendor you pay to hear you, prioritize your issue, and fix your problem, to lobbying an open-source Project Management Committee to get your feature/issue resolved.  

Who Will Shave the Yak?

Yak shaving is programming lingo for the seemingly endless series of small tasks that have to be completed before the next step in a project can move forward.

Taking on open-source development and having your employees contribute to projects inevitably leads to questions about engineering resource allocation.  Which projects will the team contribute to? Which engineering problems will they solve?  Will working on low-level primitives of an open-source messaging framework be appealing to employee engineers if it's their job for the next 2 years?  How will you rotate folks across projects if only one employee has committer rights on a project? What happens if that employee leaves and joins a competitor, taking their influence over a project with them? All of this leads to the meta question as to whether or not it's better to have a vendor take care of shaving the yak--or at least part of it. 

The Almighty Budget

Moving to self-supported open-source is essentially a build vs. buy equation. The capital cost of buying proprietary software or support from COTS vendors will move to hiring, training, and retaining engineers--and most companies incur additional costs associated with building out "open source program offices." Aside from costs, engineering managers need to be great at attracting, hiring, and retaining engineers. A robust recruiting function will need to be maintained perpetually, as will great HR professionals/processes, benefits, etc. All of this means that budgets will need to be created/programmed to accommodate higher HR/people and other G&A costs and companies will need to level up their engineering management and leadership.

Summary

In wrapping up, Porsche's bold step mirrors the future trajectory many businesses are likely to embrace. While open-source software presents a myriad of advantages, its challenges are equally profound. As the ecosystem evolves, businesses will continuously need to weigh the pros and cons and navigate this transformative journey thoughtfully.