In Code We Trust?

21 min readSep 4, 2019

A movement is growing to evolve open source — before it’s too late

“You look at where you’re going and where you are and it never makes much sense, but then you look back at where you’ve been and a pattern seems to emerge. And if you project forward from that pattern, then sometimes you can come up with something.”
― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry into Values

Software in Crisis

Software may be eating the world but that world feels increasingly precarious. Planes hurtle down from the skies due to unforeseen glitches in their software controls. Computer algorithms feed on themselves to turn a minor blip in a regional commodities market into a worldwide stock market crash. Firmware inside pacemakers and insulin pumps can get hacked with potentially lethal outcomes~~.~~…

Such fiascos have now become commonplace signals that software is in crisis — a crisis that has as much to do with the value that software delivers as it has to do with its quality of that software. In the wake of its growing severity this crisis is causing major headaches across most industries. An article by James Somers in the Atlantic Monthly a couple of years ago [from Sep, 2017] and somewhat dramatically titled, “The Coming Software Apocalypse,” actually seem quite prescient. This article provided a meticulously researched argument for the risks as a society we are taking because so much of the software on which our lives and well-being depend is a tangled mess of “spaghetti code.”

Before offering further observations, allow me to layout some context of how I see the world. I studied computer science at Cornell before moving on to developing and promoting software-centric products in a range of both world-class companies and venture-backed startups. Most of the software products with which I worked had to be fault-tolerant, protect user privacy, be compliant with international standards, resist cyber-security intrusions, and offer 99.99%+ uptime through distributed networks scattered across global locations. Such experiences instilled in me the challenges of keeping up with the behavior of interconnected systems that unfolded in complex ways as the related software went through its own evolution and incremental change cycles.

Somers’ article that I referenced earlier reminds us about how many programmers still work: “You’d sketch something, try something, you’d organically evolve it…they google, they look on Stack Overflow and they get snippets of code to solve their tactical concern in this little function, then they glue it together, and they iterate. That’s completely fine until you run smack into a real problem”. The article describes some of these problems — from bugs in cars’ onboard computers that allow their controls to be hijacked to emergency dispatch systems that didn’t anticipate potential failure modes during surges of 911 calls. As the article points out, many industries — from auto to avionics and more — don’t recognize that they are rapidly morphing into software businesses and software can no longer be an “afterthought.” Somers notes that increasingly developers are divorced from the “context” of what they are building. Their software may in fact meet all the specs for which it was designed (and represent high quality) but still fail to deliver value because it was told to do the wrong thing! Somers’ article goes on to make trenchant recommendations about the importance of training developers to embrace model-oriented code design and similar approaches [TLA+…] that can help rescue software quality from the growing complexity of the underlying systems by ensuring that developers are much more intimate with the value that code they are building needs to deliver.

Enter the Future of (Coding) Work

Yet, as is true with any complex issue, the software industry’s crisis too has multiple facets. One of these is detailed by Bret Waters (who is an innovation management researcher at Stanford University) in “The rise of that Stack Stitcher (and the decline of the coder)” that appeared in Medium in Jan, 2019. Waters believes that “we’ve reached peak code. From this point forward, coders will be in decline. We’re now entering the era of the Stack Stitcher. Today, building powerful software applications is less about writing new code and more about stitching at technology stack together using the incredibly powerful code libraries and services that already exist… leveraging millions of lines of code written by experts who are not on payroll. A whole new paradigm has arrived.”

The paradigm that Waters’ article heralds is also diffusing across a range of other industries characterized by modular value chains[1]. Future articles in my series will delve into other domains and market segments where the “stack-stitching” paradigm can in fact transform the future of work. Examples include value chains involved in the work of quantitative financial trading, 3D printing design, chemical formulations design, food processing, and so on. For the purposes of this article, suffice to say that Waters’ insights do seem to reconcile with how software practice is evolving in Silicon Valley and other hotbeds of software development. However, his article made me wonder how prevailing collaboration tools and development environments will evolve as most of them don’t provide mechanisms to verify code that is being cross-pollinated. Enterprises and developers don’t understand the provenance of the code they are building. Because they don’t know where the code came from, or where it’s been, that code remains vulnerable to malware, safety issues, and infringement risks. And, when you multiply these risk factors with the risks inherent in the evolution of critical software systems that Somers has pointed out we are now compounding the chance that “disasters waiting to happen” will manifest.

The Implications for a Post Open Source World

For those of us raised in the Open Source ethos, the trend-lines noted above cause serious cognitive dissonance. Open Source was and still is built on embracing a set of values that cherish collaboration, open exchange, rapid prototyping, transparency, and community-oriented development. Weren’t issues with code robustness, security, control, and even training supposed to be solvable within and through fertile exchanges among open source communities? If code for, say, self-driving car control systems could be brought into the open source way then wouldn’t the ground swell of developers who are tinkering, adapting, and building on that code drive us into much more secure, safe, and effective code for all? Wouldn’t the rash of software services and support that spring up for helping users install, use, and debug open source code reward the service providers while generating value for the open source community (as has happened with the virtuous cycles that helped spawn leading open source ecosystems)?

Although these are clearly possibilities, the inconvenient reality is that open source is suffering from a tragedy of the commons that makes the “open source way” increasingly difficult to sustain. Even as open source usage has grown exponentially, the resources required to maintain, enhance, “peer-review,” let alone stack-stitch, code haven’t kept pace. While code repositories and collaboration platforms have proliferated, sustainable models to incentivize developers to maintain, update, stabilize, and enhance others’ code are still lagging. As a result, the promise of the open source movement doesn’t jive with the operating realities and costs of:

Security; open access to open source doesn’t mean that security weaknesses have been flagged by all those tinkering with it.
Customization; customization renders open source code closer to “closed source” so that you need to support ongoing maintenance for the customized version
Update integration; especially when the open source developer community stops supporting an old version of the software, even it may be working in your environment,
Recruiting; enlisting appropriate developers who have experience and demonstrated expertise with particular types of code can be a major risk factor for mission critical projects

A rash of recent entrants are attempting to resolve these issues by offering users access to groups of “maintainers” paid through subscription-based models. While this is in some ways a welcome development, it doesn’t resolve the fundamental issue of sustainability. Ideally, most code should be open and sustained through various forms of community dividends — rather than mercenary maintainers who could have mixed agendas. In this regard, proposals inspired by Posner and Weyl’s hugely acclaimed recent book, “Radical Markets,” advance suggestions for imposing “taxes” on code that becomes “private” or “closed” thereby encouraging code to be made public and open to the community. Such proposals are intended to break the “Property as Monopoly” syndrome that afflicts our societies — and certainly embody a stronger community-minded spirit than private armies of mercenary maintainers. By proposing that any property can trade ownership provided the holder is paid their self-assessed value for that property and levying a community-originated tax on code that stays proprietary, Radical Markets-based proposals seek to grow the value of the community’s code by attempting to re-claim value that the community may have lost when code is removed from public access. Yet, even permissive open source licensing has been notoriously difficult to enforce in practice and attributing “taxes” based on self-assessed valuations might sound ingenious but suffers from the practical difficulties around correctly valuing non-fungible intellectual assets such as software code. Even if one were to set an arbitrarily low value for one’s code then as long as it remains sufficiently “special-purpose,” one may not need to worry about anyone disrupting one’s “monopoly” power because a high degree of specialization can, in practice, impede fungibility.

Having spent many years generating and trading intellectual asset value for enterprises from scrappy start-ups to Fortune 50 multinationals, I recognize that even the Radical Markets based proposals don’t adequately allow for the reasons that large amounts of the world’s software code remain locked-up in closed repositories. Individual developers often have un-utilized code just as large enterprises have large volumes of code that could be out-licensed — yet the process around licensing remains cumbersome and fraught with risks of theft or infringement. Thus, closed code requires significant non-linear impetus to be opened to the public and open source suffers from all the problems of securing and sustaining it that have been mentioned previously. As a result, software development remains a fragmented, unwieldy, complex bereft of the efficiencies and rigorous community review that could mitigate the risks noted by Somers or capitalize on the opportunities highlighted by Waters.

The hybrid model (Next Gen Open Source)

Despite this dynamic, we are also seeing a commodification of code as the following table illustrates:

[Excerpted from Adrian Cockcroft, “Velocity and Volume (or Speed Wins),” presentation at FlowCon, San Francisco, CA, Nov 2013].

This table anticipates a mega-trend that is now well developed — the “containerization” of code. The huge growth of Docker and Kubernetes are part of this trend as developers opt to increasingly opt to more tightly integrate development and operations tasks.

We know that containerization has been a game-changer in industries ranging from transcontinental shipping to internet packet switching. How can we leverage this inexorable growth of containerization toward a new paradigm for a post-open source world?

Imagine a platform for code development that is sustainable that is a hybrid of the best practices of private code (reliability, customization) with the benefits of open source (novel, easy to access, peer-reviewed for security and other functionality). Such a platform pays contributors who help with validation and also rewards participants for building on others’ code transparently and efficiently. Such a borderless, trusted exchange would be open to all, with users and holders being brought together because their registered interests have been mapped and cross-pollinated by autonomous bots. A safe zone that rewards scouts who find security flaws or validate code or rate how “clean” and complete the related the functionality and documentation is regardless of whether that the code is open or closed — based, of course, on permission-based access to conduct such security reviews being granted by the holders. A self-correcting set of governance rules and principles based on transparency and consensus that deters mercenary behaviors. A paradise for creative spirits where coders can monetize their output seamlessly by being matched with potential buyers, with licensing agreements being managed by smart contracts.[2]

Let’s develop some heuristics for the value that such a platform could help generate. According to estimates from IDC, Gartner, and other industry analysts, the global software industry is approaching an annual spend of $4 trillion. Assume that just 10% of this annual spend — around $400M — is wasted as a result of the issues of rework, security gaps, functionality mismatches, and value degradation noted in this article [the actual economic loss is likely much higher]. However, if the platform we conceptualized could help reduce this loss and re-invest that same spend it could conservatively drive gains of 2–3x. In other words, the platform could drive value creation of over $1 trillion!

I’m thrilled to announce that InvenTrust has taken the first steps toward operationalizing such a platform. We are enabling the world’s first exchange for trusted software code by generating a rich set of incentives for the community that is facilitating the vetting and transaction of code components. Through this approach we intend to build an alternative that heals the schism between closed and open repositories to help evolve next generation of open source. Of course, we hope that our approach can help defuse the software industry’s crisis by spawning code we can all trust. We expect to deliver transformative value by significantly enhancing cost and cycle time for critical software systems. However, as is true with any community-led commons our paradigm may be disproportionately embraced even by developers looking to stack-stitch millions of code components, Dev Ops set-ups (such as within Docker or Kubernetes), serverless apps, low-code software, IoT kernels, security components, frameworks, and more to shape-shift the quality and value that they can deliver through a trusted commons.

Given that Open Source itself describes a movement that began to accelerate in the last decade, we anticipate that the evolution described here too will have manifestations outside software. In effect, a movement is growing for incenting collective innovation; a topic that will be the subject of a spate of articles from collaborators associated with our project and beyond.

This harkens back to the reference with which I started this article — to Pirsig’s timeless book, “Zen and the Art of Motorcycle Maintenance” — was intended to draw attention to what it takes to build such trust. Pirsig was a maverick writer-philosopher who wrote computer manuals into the wee hours outside of his day job and was as unfazed by rolling up his sleeves to care for motorcycles as he was with inquiring into the values that help grow human potential. Z.A.M.M. stunned the publishing world (Pirsig was rejected by 23 publishers before he found the publisher who saw in it an American classic after the tradition of Moby Dick) by selling 5 million copies and its ideas have endured as they are a meditation on the pursuit of both quality and value.

Share your feedback on, how to make the experience you discover at www.inventrust.com a step toward that zen-like direction that enhances value for our community.

[1] In Modular Value Chains, Holders transmit complex but codified information to Users which the Users can flexibly put to use since many of the factors of production involve similar infrastructure and machinery. As a result, coordination requirements are low provided industry-specific codification standards are followed. (By comparison, Market Value Chains involve less complex transactions and Relational Value Chains involve transactions that cannot be adequately codified.) Thus, Modular Value Chains often lead to the highest premiums for the underlying rights.

[2] The ongoing performance of transacted codes influences reputation scores and royalty payments which are also managed through smart contracts. These contracts further ensure that the various contributors to code assets receive royalties for their enhancements.

That suchSuch fiascos have now become commonplace signals that software is in crisis — a crisis that has as much to do with the value that software is deliveringdelivers as it has to do with its quality of that software. In the wake of its growing severity this crisis is causing major headaches across most industries. An article by James Somers in the Atlantic Monthly a couple of years ago [from Sep, 2017] and somewhat dramatically titled, “The Coming Software Apocalypse,” actually seem quite prescient. This article provided a meticulously researched argument for the risks as a society we are taking because so much of the software on which our lives and well-being depend is a tangled mess of “spaghetti code.”

Before offering further observations, allow me to layout some context of how I see the world. some observations from this and other notable articles as part of my own thesis in this post, let me say that I studied computers at a university renowned for itsI studied computer science at Cornell offerings before moving on to developing and promoting software-centric products in a range of both world-class companies and venture-backed startups. Most of the software products with which I worked had to be fault-tolerant, protect user privacy, be compliant with international standards, resist cyber-security intrusions, and offer 99.99%+ uptime through distributed networks scattered across global locations. Such experiences instilled in me the challenges of keeping up with the behavior of interconnected systems that unfolded in complex ways as the related software went through its own evolution and incremental change cycles.

Somers’ article that I referenced earlier reminds us about how many programmers still work: “You’d sketch something, try something, you’d organically evolve it…they google, and they look on Stack Overflow and they get snippets of code to solve their tactical concern in this little function, and then they glue it together, and they iterate. And tThat’s completely fine until you run smack into a real problem”. The article describes some of these problems — from bugs in cars’ onboard computers that allow their controls to be hijacked to emergency dispatch systems that didn’t anticipate potential failure modes during surges of 911 calls. As the article points out, many industries — from auto to avionics and more — don’t recognize that they are rapidly morphing into software businesses and software can no longer be an “afterthought.” Somers notes that increasingly developers are divorced from the “context” of what they are building. Their software may in fact meet all the specs for which it was designed (and represent high quality) but still fail to deliver value because it was told to do the wrong thing! Somers’ article goes on to make trenchant recommendations about the importance of training developers to embrace model-oriented code design and similar approaches [TLA+…] that can help rescue software quality from the growing complexity of the underlying systems by ensuring that developers are much more intimate with the value that code they are building needs to deliver.

Enter the Future of (Coding) Work

The Implications for a Post Open Source World

For those of us raised in the Open Source ethos, the trend-lines noted above cause serious cognitive dissonance. Open Source was and still is built on embracing a set of values that cherish collaboration, open exchange, rapid prototyping, transparency, and and community-oriented development. Weren’t issues with code robustness, security, control, and even training supposed to be solvable within and through fertile exchanges among open source communities? If code for, say, self-driving car control systems could be brought into the open source way then wouldn’t the ground swell of developers who are tinkering, adapting, and building on that code drive us into much more secure, safe, and effective code for all? Wouldn’t the rash of software services and support that spring up for helping users install, use, and debug open source code reward the service providers while generating value for the open source community (as has happened with the virtuous cycles that helped spawn leading open source ecosystems)?

1. Security; open access to open source doesn’t mean that security weaknesses have been flagged by all those tinkering with it.

2. Customization; customization renders open source code closer to “closed source” so that you need to support ongoing maintenance for the customized version

3. Update integration; especially when the open source developer community stops supporting an old version of the software, even it may be working in your environment,

4. Recruiting; enlisting appropriate developers who have experience and demonstrated expertise with particular types of code can be a major risk factor for mission critical projects

Having spent many years generating and trading intellectual asset value for enterprises from scrappy start-ups to Fortune 50 multinationals, I recognize that even the Radical Markets based proposals don’t adequately allow for the reasons that large amounts of the world’s software code remain locked-up in closed repositories. Individual developers often have un-utilized code just as large enterprises have large volumes of code that could be out-licensed — yet the process around licensing remains cumbersome and fraught with risks of theft or infringement. Thus, closed code requires significant non-linear impetus to be opened to the public and open source suffers from all the problems of securing and sustaining it that have been mentioned previously. As a result, software development remains a fragmented, unwieldy, complex bereft of the efficiencies and rigorous community review that could mitigate the risks noted by Somers or capitalize on the opportunities highlighted by Waters.

The hybrid model (Next Gen Open Source)

Despite this dynamic, we are also seeing a commodification of code as the following table illustrates:

1970s-1980s

1990s

2000s-Present

Era

Mainframes

Client/Server

Commoditization and Cloud

Representative technology of era

COBOL, DB2 on MVS, etc.

C++, Oracle, Solaris, etc.

Java, MySQL, Red Hat, Ruby on Rails, PHP, etc.

Cycle time

1–5 years

3–12 months

2–12 weeks

Cost

$1M–$100M

$100K–$10M

$10K–$1M

[Excerpted from Adrian Cockcroft, “Velocity and Volume (or Speed Wins),” presentation at FlowCon, San Francisco, CA, Nov 2013].

I’m thrilled to announce that my organizationInventrustInvenTrust has taken the first steps toward operationalizing such a platform. We are enabling the world’s first exchange for trusted software code by generating a rich set of incentives for the community that is facilitating the vetting and transaction of code components. Through this approach we intend to build an alternative that heals the schism between closed and open repositories to help evolve next generation of open source. Of course, we hope that our approach can help defuse the software industry’s crisis by spawning code we can all trust. We expect to deliver transformative value by significantly enhancing cost and cycle time for critical software systems. However, as is true with any community-led commons our paradigm may be disproportionately embraced even by developers looking to stack-stitch millions of code components, dDev Oops set-ups (such as within Docker or Kubernetes), serverless apps, low-code software, IoT kernels, security components, frameworks, and more to shape-shift the quality and value that they can deliver through a trusted commons.

Share your feedback on, how to make the experience you discover at www.inventrust.com a step toward that zen-like direction that enhances value for our community.

In Code We Trust?

Written by InvenTrust