How has the recent turmoil within the OpenAI offices changed your plans to use GPT in a business process or product in 2024?
Increased uncertainty means we are more likely to evaluate alternative AI chatbots and LLMs.
No change in plans, though we will keep an eye on the situation.
With Sam Altman back in charge, we are more likely to go all-in with GPT and LLMs.
What recent turmoil?
Software Development / Tech Life

Part 1: Operationalize the Enterprise Developer

The critical question with a developer relations program is: Can developers use your tools to deliver more value in a shorter amount of time?
Feb 26th, 2021 11:00am by
Featued image for: Part 1: Operationalize the Enterprise Developer

John Mark Walker
John is the Director of the Open Source Program Office at Capital One. Before joining Capital One, John was a long-time practitioner and advocate of open source collaboration, leading open source efforts at Red Hat, EMC, Gluster, Hyperic and SourceForge.

Developers, developers, developers!

Technology vendors have screamed for more developers ever since it became clear that they’d become a lot more influential in the technology landscape. It was Microsoft who coined the phrase “developer ecosystem” in the 1990s. This environment for developers became a foundation that fueled Microsoft’s growth, enabling it to become a juggernaut that was the envy of technology companies worldwide. Ever since, every large technology company has dreamed of owning the developer space, with its attendant influence and center of gravity that is shaping the future of enterprise platforms.

Many companies have turned that tried-and-true playbook into success. Microsoft created consistent APIs and a wealth of developer documentation so that thousands of consultants and independent software vendors could build customer bases on Microsoft’s significant operating system market share. VMware created an easy way for developers to build and deploy apps right from their workstations, without the need for interference from stingy ops people. Apple created the world’s most successful small device operating system, iOS, and used its leverage to turn its third-party marketplace into a market force that sustains its continuing growth. Amazon created a massive compute infrastructure that gave developers even more control over their software development lifecycle, building a vibrant tech garden where a million startups grew. All these examples have a few things in common:

  • They used developers to establish a growing center of gravity around their leading platforms
  • They helped resolve developers’ biggest pain points
  • They allowed developers to shorten the time to value for their respective employers  —  and they operationalized third-party developers

What ‘Operationalize’ Means in This Context

The critical question to ask (and answer) with any developer relations program is straightforward: Can developers use your tools to deliver more value in a shorter amount of time?

This question seems relatively simple, but let’s examine what it doesn’t ask. Many vendors have developed snazzy, whiz-bang tools for developers, but the most significant factors are a compelling platform (that developers actually want to use) and shorter time to value. In these instances, the platform attracts developers, who drive platform growth in a symbiotic relationship that fuels a positive feedback loop.

Can you be successful as a technology company without developers? Sure, but the examples above demonstrate wild success  —  levels of success that are difficult to imagine without a strong developer community. It’s safe to say that how well you operationalize developers can mean the difference between modestly succeeding and wildly exceeding expectations. Developers have significantly increased in importance; and in a world of technology kingdoms, enterprise developers are kingmakers.

This begs the question: What does the enterprise developer want?

Enterprise developers want power and simplicity. They want tools that ease their pain and allow them to focus on writing code without too much overhead. But the enterprise developer in 2021 wrestles with too many choices, increasing complications, and too much overhead.

Today’s developer market is an interesting mix of platforms and tools in a minefield of developer experiences. Today’s enterprise developers use old software libraries because those old libraries work, despite potential vulnerabilities. Because everyone has adopted DevOps principles, they are all saddled with maintaining their applications over the long haul, dealing with much overhead as a result.

While maintaining their apps in a You Build it, You Own it (YBYO) universe, they’re also resolving the same issues with common libraries that hundreds of other discrete teams are addressing concurrently. For example, every development team affected by a bug in a specific library will spend time manually patching and fixing the software.

Because vendors haven’t addressed the open source sustainability problem, they don’t prioritize contributing fixes upstream  —  and most large corporations haven’t figured out how to integrate upstream fixes into their everyday workflow. The mantra “write once, run everywhere” has become “write a hundred times, deploy a hundred times, fix and remediate a hundred times.” The paradox of choice has led enterprise developers down a path that they simultaneously adore and loathe.

Complexity often goes hand in hand with large-scale computing, but much can be done to improve the developer experience.

Operationalize This

Let’s go back to the central thesis: How to operationalize the enterprise developer. Turning to the previous theory that a compelling platform and developer ecosystem leads to wild success, what would a successful developer platform look like? It would:

  • Automate the usage and maintenance of open source libraries. Open source libraries are here to stay. There is no denying the speed of development that it facilitates and it provides an easy way to mitigate risk with many contributors.
  • Provide a common set of building blocks and platforms. Easier said than done, right? There are two basic approaches: Either create an abstraction that provides a compatibility layer for developers or push a core platform that wins the market. History tells us that the latter approach is more successful. And in this modern era, any application building block that doesn’t include or build on Amazon Web Services faces a significant mountain to climb.
  • Provide a common framework for managing applications at scale. Is it a Kubernetes variant like Critical Stack?

Looking at the computing landscape now, any given solution could conceivably serve the purpose of easing developers’ pain while also allowing them to deliver value more quickly. It seems the easiest path is a platform that utilizes cloud infrastructure and wins developer hearts and minds, by integrating seamlessly into their existing tools and workflows. In short, the winner will be a cloud accelerator.

Given the lack of available comprehensive solutions for the developer experience, with none on the immediate horizon, or even a set of reliable building blocks to quickly assemble a solution, what can we do? I’ll cover this in my next article…

Feature image via Pixabay.

Group Created with Sketch.
TNS owner Insight Partners is an investor in: The New Stack, Pragma.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.