At the Crossroads of Open Source and Open Standards – InApps Technology 2022

This piece is the first in a series from speakers and sponsors at the Linux Foundation’s Node+JS Interactive (formerly JS Interactive), conference, taking place October 10-12, 2018 at the Vancouver Convention Centre, in Vancouver, Canada. The program will cover a broad spectrum of the JavaScript ecosystem including Node.js, frameworks, best practices and stories from successful end-users.

A new crop of high-value open source software projects stands ready to make a big impact in enterprise production, but structural issues like governance, IPR, and long-term maintenance plague OSS communities at every turn. Meanwhile, facing significant pressures from open source software and the industry groups that support them, standards development organizations are fighting harder than ever to retain members and publish innovative standards. What can these two vastly different philosophies learn from each other, and can they do it in time to ensure they remain relevant for the next 10 years?

What We Mean When We Say “Open Source”

For avoidance of doubt, “open source” refers to unincorporated communities that have organized around a particular code base and selected permissive licenses for that code base in order to facilitate greater adoption and sharing. While these communities are increasingly the product of a corporate open source effort, the projects themselves are primarily defined by their code and the restrictiveness of their licenses, with some nods to how it was developed (in a decentralized way). Ultimately, the success of an open source project depends on the clarity of the vision for that project, on strong definitions of basic functions, and a clear strategy for how the project will evolve and adapt over time.

Developer and Enterprise Benefits of Open Source

One needn’t look far to find examples of high-quality open source software projects making a big splash for software developers and the enterprise. Node.js, for example, provides a JavaScript runtime outside the browser context, allowing developers to write programs for the server, command line, or single-board computer. Here, the JS developer can expand their skill set beyond web development without having to learn a whole new programming language.

React, an open source project for user interfaces developed at Facebook, simplifies some of the complexity issues of MVC-based libraries, giving front-end developers the ability to focus on issues that directly impact users: namely performance and accessibility. And the npm package manager was created to help developers manage the growing number of packages and dependencies required for modern web development. The result feels like a win-win: software developers are spending less time writing boilerplate code and more time poking around problems that actually interest them, while companies are spending less developer time and R&D budget on non-core tech issues.

It’s Much Harder Than it Sounds

All of the aforementioned projects have also had significant, non-technical stumbling blocks disrupt or completely halt progress toward what should have been a straightforward entry into enterprise production.

Project governance issues in Node.js led to a temporary, high-profile fork of the project during a period of high-tension between community-driven technical project maintainers and the business-driven needs of its main corporate controller, Joyent. Though the two forks eventually remerged under the Node Foundation, the wounds of the split are still healing for some, and the public nature of the split certainly gave many companies serious pause about adding Node.js to their stack.

Multiple changes to React’s license and patent policy over the course of 4 years led to debates about whether the project’s open source license had been nullified, and caused some high-profile React users like WordPress to announce they were dropping the project entirely (React is now MIT licensed, but similar debates are currently happening with Redis and Lerna).

Persistent maintenance, stability, and security issues in npm – which grew along with the number of published packages – led Facebook to develop and open source a competing project, Yarn. And in countless frameworks such as Angular, the desire to rebuild core parts of the tooling has resulted in organizations getting locked into older versions of the tool as they break backwards compatibility. These issues convey project instability, and deter adoption for organizations that either don’t have the engineering bandwidth or otherwise can’t put forth the time and effort to monitor the situation closely enough to determine whether it will impact them.

Governance, IPR, and long-term maintenance issues in software pre-date the Internet, but the rapid pace of innovation in modern open source software production exacerbates the problem. Technologists are well equipped to address technical issues, but “human interoperability” problems can’t be treated with the same black-and-white rationality. It takes time and energy to examine the implications of and build consensus for sociological issues, and managing that process requires a different set of skills.

Open source communities are increasingly seeking human-centered approaches to address how they organize about and maintain their code, but many lack the support structures to execute effective solutions. Depending on their experience or project goals, open source project maintainers may not be considering financial, market, or other long-term issues that help make sure the project can remain a going concern. Further, solutions for these problems are time-intensive, and time is already a precious commodity among developers who are sharing their craft for free.

Companies may be willing to “fund” developer time on an open source project in order to support a critical piece of code or retain that employee, but company support of open source rarely extends to non-technical contributions. To the extent that companies engage in a technology beyond the code at all, it is usually to exert some form of market or product control – a pattern that has been true since the industrial era. Starting in the 1840s, standards development organizations (SDOs) have been convening companies to discuss and debate technical issues in a given industry, and helping prevent any one entity from running away with the field.

The Legacy of Standards Development Organizations

Modern SDOs that focus on web technologies are the W3C, Ecma International, WHATWG, and IETF. These organizations vary quite a bit in terms of their policies, structures and the technologies they work on, but their objectives are generally the same: convene interested parties and relevant stakeholders (web developers, browser vendors, academia and industry); assess, debate, and determine how a given technology should be specified; and adopt that specification as a standard (or recommendation) for an industry to adopt.

It’s important to note that working groups don’t always produce specifications that get adopted as standards — the failures are often more meaningful than the successes — but standardization activities are an important prerequisite to the deployment, use and maintenance of shared infrastructure. The success of a standard can be measured by the number of implementations of that standard, how interoperable it is with other standards and systems, and how much value it creates (and how much value it allows implementers to capture).

SDOs: An Industry in Transition

Maintenance and vision-setting of a standardized platform takes a significant amount of time and resources. SDOs — even web tech SDOs — have a reputation for moving slowly, and the rise of open source communities has companies wondering why they ought to bother with standards development in the first place. Unfortunately, the role of the SDO as a group that “locks in” interoperability wins seems less important when companies are willing to reinvent their tech stacks every two to three years. SDO memberships can seem like a frivolous expense when its “innovation” appears to be happening elsewhere.

Web-focused SDOs have been gradually adopting royalty-free policies, and are moving a lot of their standards work from a traditional, industrial-product focused process to an open standards process. Open standards refer to specifications that are collaboratively developed in an SDO or consortia and that: 1) group membership is accessible, 2) the standard itself is available in either royalty-free (RF) or reasonable and non-discriminatory (RAND) means, and 3) decision-making and due process are explicitly defined and consensus-based. Increasingly, web-focused SDOs are adopting more “open source” like practices, including the RF IPR policies and conducting work and posting minutes in public and on forums like GitHub. But there is a lot of overhead in doing patent-clearing for the RF licenses, and the learning curve for working in the open can be steep.

The Venn Diagram of Open Source Communities and Open Standards

Philosophically, open source and open standards groups are more alike than they are different. The goals of community-driven open source are based in a general desire to create an immense amount of shared value that anyone is free to capture. Similarly, SDOs exist to create, and help their members capture, value from building shared IP. Open source and open standards advocates share similar ideas about how an open project should be governed, with the trend being that more parties should be at the table. Both groups value good documentation and clear process.

Both camps take different approaches to these ideas, though. In general, open source software communities are better at innovating in the open, quickly prototyping or proving out concepts to see what has “staying power,” and fostering healthy communities through outreach and critique of key issues, such as diversity, inclusivity, and ethics in tech. SDOs are generally better at adhering and enforcing process, maintaining historical archives and documentation, working through legal issues, and getting non-technical stakeholders to the table.

What Can These Groups Learn from Each Other?

These two groups stand to learn a lot from one another, if only they could find better ways to connect and align:

• SDOs can convene key stakeholders, but do not hold technical knowledge themselves (that is provided by the SDO membership). SDOs can get a diverse group of perspectives to the table, but the can’t foster a community around that table nearly as well.
• Conversely, open source projects are a truer barometer for long-term technical innovation, which is informative to what SDOs should standardize, but open source projects often lack the structure and support to maintain over time. Open source projects create a lot of shared value, but struggle with the legal IPR strategy for how to protect that value.
• SDOs are able to stay more in touch with communities on the platforms they standardize, and can continuously learn from open source experimentation while serving as a trusted connection between industry standards needs and the communities building (and building on) cyberinfrastructure.
• SDOs tend to have access to stakeholders outside the “tech bubble” – policymakers, academics, ethicists, business executives and so on, whereas open source communities tend to be communities of potential implementers. In other words, these groups are ideal target customers for one another.

There’s a lot of potential for collaboration, and some easy gains to be made in doing so. Better alignment could help open source projects, affiliated with an SDO, to receive early access, advice, and support on legal and governance matters, including boilerplate for CLAs, process, and other industry-acceptable documentation that is consumable beyond the technical sphere. SDOs could provide access to a line of funding via grants to help support or achieve platform-impacting goals. Meanwhile, this alignment helps SDOs spot the areas of the platform most in need of standardization, and gives them a pipeline of new work to formally standardize in the future.

Without collaboration, both groups face a far more uncertain future. Both will lose access to a diversity of perspectives and technical opportunities, insight about the direction of the platform, and perceived relevance if current trends continue. Open source communities and SDOs are important champions of the platform, and they must unite in order to continue the fight.

The Linux Foundation is a sponsor of InApps Technology.

Feature image via Pixabay.