James Governor, analyst and co-founder of RedMonk, sat with Sacha Labourey at DevOps World | Jenkins World, Nice to catch up on software development and deployment and discuss which companies were doing it well. Before they tackle the future of DevOps in Episode 44, they revisit the past (think: Sacha’s JBoss days) and what James admits is not his finest moment as an industry analyst in regard to some “hogwash” on the decoupling of open source.
From there, they dive into a new-ish concept with a newer title - progressive delivery . James shares his perspective on the interaction between IT and the business if you decouple deploy from release. He notes one needs to look at the bridge between what an enterprise customer and what web companies are doing. His solution? Train the people in organizations first, or at least give IT the green light to keep deploying software and services, but let businesses decide when to activate it. It’s not enough to just spin the IT wheel faster. If organizations want to have an impact loop, they need to involve the business stakeholders that understand the users of the service, and how they should be integrated into the process.
Shaping the future
One of the benefits of continuous delivery is that it allows organizations to reshape the value of the company. James provides examples including Tesla - where they sell on the promise of further innovation to come; and Amazon - where there are services that stand up but not fully realized.
Although it’s been said time and time again that “every company is a software company,” James is wary of this statement and in fact, believes every company should be a tech company. If you’re confused between the two, James breaks down what he means by software vs. tech. Software companies sell software while technology companies sell services that you run on, he explains. The difference comes down to how the digital experience and software services are packaged.
James also voices his concerns that open source is solving the wrong problems. While many organizations (like Amazon) are packaging open source software and getting a market advantage, this presents a frustration for people who build the software.
Indeed, he believes building restrictions into how open source software can be used isn’t an answer to this. It’s the job of tech companies to package software services and data so that the products appeal to the customer and the audience is willing to pay for. To accomplish this, organizations have to evaluate use cases where they want a customer to pay for the proprietary software. This leads James to ponder one final thought: maybe there shouldn’t be software companies?