Open Source Challenges in New Industry Spaces

Stephen Walli
Nov 4 · 7 min read

I have the privilege of having been invited to participate in the LF Energy Summit here in Paris early November. As I read more about the energy sector to get a sense of the problem the group wants to tackle, I see a set of possible challenges they will need to meet as they tackle such a broad important space, introducing open source into a new industry.

Industry Structural Challenges

I have only participated on the fringe of the LF Energy discussions, and it appears there are multiple large different, separate industry initiatives that are converging on LF Energy. They involve areas as broad as energy generation, transmission, renewables, and electric vehicle infrastructure. Industries have a shape with respect to their historical economics and investment practices, and regulatory and legislative engagement. These create specific challenges when engaging in the world of open source projects.

Legislation challenges: I’ve seen situations where governments wanting to work together to collaborate couldn’t because of legislation on the books preventing software created with tax dollars being shared outside the tax base. One wealthy state with a strong tax base had built a software system and wanted to publish it under an open source license and build a simple community. A few smaller states with smaller tax bases were using the software and wanted to submit changes but couldn’t because their state laws prevented software created with state taxes from being used outside the tax base. Even the initial share out was somewhat done under a don’t ask don’t tell blind. I’m not sure if government regulatory agencies or legislative bodies will inflict this challenge of the group, but they should be aware of the possibility so they can find creative ways to solve for such challenges.

Standards vs. Open Source Collaborative Challenges: Industries that are traditionally steeped in standards are surprised that engineers collaborating in an open source project isn’t similar to engineers collaborating on a standard. This is complicated because IT customers will say ‘open source’ to mean ‘no vendor lock-in’ and as an evolution of ‘open standards’ (the ’00s) and ‘open systems’ (the ‘90s). IT customers see this as a progression in language.

Standards, however, are very different engineering collaborative engagements. Standards are late market tools. They encourage many implementations. It’s a negotiated compromise driven by democratic influence. Open source community collaboration is more of a leading collaboration, where the project builds the one true implementation (potentially then used in many products), and it is run in some form of a meritocracy via contributions upstream. If an industry has been historically standards bound (because of a regulatory climate for example), then understanding the difference in engineering collaboration comes as a surprise.

Standards generally take a few years to settle into a stable release. It gives the engineers time to really debate and test the edges as they knit together their divergent experiences into a stable specification. It gives companies with products time to ensure product release cycles can meet the standard. Those standards then change cautiously and conservatively because no one (neither customer nor vendor) wants a standard’s change to start breaking the conforming products in the market. Good open source projects, on the other hand, start with working code that solves the core of the problem statement then evolve rapidly (assuming the work is done to build healthy community).

Saying ‘open source’ is the new ‘standards’ is a dangerous mistake. Believing standards can now be created at the speed of open source collaboration is simply incorrect. When industries with a long history of standards collaboration begin to collaborate in the open source world, they need to understand the differences they will encounter.

Industry Economic Challenges: Open source was created in the world of IT software infrastructure for the most part. Investment money flows in a particular way, and how vendor participants in that ecosystem think about those investments and protecting them (e.g. copyright, patents, trademark) has evolved over the past 40 years but follows a pattern unique to IT software. There are situations in other industries, however, where the overall economics drive a different intellectual property regime. This is the how-innovation-money-flows-in-an-industry challenge.

For example, Telcos live in a world that is capital intensive and heavily regulated (both in-country and cross border). The way Telcos collaborate historically on standards is to invest in capital intensive R&D, patent everything, have a bake-off, the clear winner is selected as ‘the standard’, the specification goes through formal ratification, and a patent pool is formed on the side to handle the cost recovery of the initial R&D investments. This is very different from the IT standards world that has evolved to be comfortable collaborating in software communities as well as standards communities.

This is one reason why Telcos are challenged by the open source space — the licensing is uncomfortable for more conservative legal teams (by possibly reading on patents explicitly or implicitly) and they have generations of depth in protecting hardware investments via patents. As everything drifts towards being ‘software defined’, this makes such players more worried, not less so. As software and hardware lines blur, this discussion will get worse.

Open Source Education in New Verticals Challenges: There is a subtle extra difference in IP management in collections of software companies in an industry vertical. Many software applications companies in non-IT infrastructure spaces are also uncomfortable with ‘open source.’ When open source collaboration is new to an industry, one sees the rhetoric of 20–25 years ago, with all the fears surfacing as a ‘destruction of intellectual property.’ These vendors hear their customers’ desires, but don’t know how to engage without risking IP loss. It can make them naïve actors in community and obstructionist.

Open Source Project Challenges

There is a collection of challenges around building strong projects themselves and getting the community engagement across a collection of developers and companies anchored around working together to build software.

Project Mechanics Challenges: Freeloaders means you’re doing it right. So many companies and projects just don’t understand this fundamental rule-of-thumb. As much work as the code is, the building of community is more so. This is the success of the Apache Software Foundation and the Apache Way with the focus on community over code, as well as the Eclipse Foundation, and the Kubernetes Project Framework.

This is an orders-of-magnitude problem. A very few are doing the work enjoyed by the many — just like every other human community on the planet. You also need to understand as you build on-ramps to encourage users from which you will find developers who you need to encourage as contributors, most users simply want to use the software, and developers want to solve their own problems. Self-interest drives participation. Your broader project community wants to use the software without necessarily contributing. Ask not what your community can do for you …

Product Mechanics Challenges: Projects are not products. Everyone gets this wrong with very few exceptions. Customers have money and no time — community members have time and no money. If you are a company that builds software for a living, then you need to understand how to build a bright line between products (and customers) versus projects (and community).

There is a secondary challenge in the product solution space as well. Publishing a large amount of product/solution code as a project — fully willing to accept patches — does not make for a successful project. Kubernetes was a reimagining of Borg. .NET Core was a massive refactoring of the .NET world. VS Code was a complete reimagining of Visual Studio. There needs to be a coherent way for the community that wants to use/build/explore the project to engage. Part of building the on-ramps for users, developers, and contributors is to ensure the project is approachable.

Industry Consortia Challenges

Industry non-profits are excellent places that can broker the discussion between participants, but they come with their own challenges.

Foundations and Ecosystems Challenges: Historically, non-profit organizations were wrapped around projects as a way to clean up the IP management such that companies could pull from projects to build products, and the project in return received more dedicated input from staffers at companies. Everyone won. It also created a legal structure to remove liability risk from participants, especially the individual project founders. Most of these non-profits were created with a focus on the public good.

As with the standards development organizations of the previous decades, these public good organizations have shifted into trade membership organizations. These create a safe legal framework for companies in an industry, some of them competitors, to have a collaborative discussion without triggering anti-trust law. But another evolution crept into the discussion.

Starting with the Symbian Foundation, then OpenStack, and now a broadening number of other organizations, there is a desire to ‘build an ecosystem.’ It sounds great — and Linux is always used as the ultimate example everyone throws around — but it misunderstands ‘ecosystem.’ Ecosystems are market design problems. They don’t happen simply by collecting together lots of members and hoping they have enough shared interest to have the right conversations and work together and then building an architecture diagram to unify the products and projects into a structure. The OSDL (and its rebranding into the Linux Foundation) was a liability shield to support the Linux project and a messaging platform. The Linux ecosystem grew from the long term success of the project and its contributors pulling Linux into a myriad of directions for their own success while contributing back.

Competitive Vendor Challenges: You also have to understand the sorts of games sometimes played out in foundations (indeed in many industry collaborations) by competitive vendors. Some vendors weaponize Brooks’s Law (“adding human resources to a late software project makes it later”) slowing work down to enable their messages or products to land a particular way. Some vendors create foundations or foundation projects to commoditize a competitor’s core technology space. When you see a set of vendors collaborating, you need to occasionally be prepared to discover it is not for the common good. Transparency in project communications is the best antidote to poor behaviour, and actual work in the community generally wins out. I don’t believe the LF Energy world has these particular challenges, but mention them for completeness.

As I participate in the discussions in Paris and look at the work LF Energy is tackling, I am cautiously optimistic.

Stephen Walli

Written by

Tech exec, Founder, Writer, Open Source Advocate, Software Business Consultant

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade