Some notes on attending conferences, notes on enterprise open source comercio-community, asides and waste book…lots of links.
Suggested epigraph and theme are on vacation this week.
I was at VMware’s big conference in Europe this past week, VMware Explore. Not too much content since last time, then.
Here is an unlisted link that only you have access to, the recording of the talk we gave at VMware Explore this week. It goes over lessons learned about running a platform for application developers - platform as a product, platform engineering, whatever. It’s based on the experience at Mercedes and a large bank:
If you’d like to share or link to it, please use the official VMware Explore listing, you know?
Early on in the life of a new open source project, some vendors will tell you it’s too complex and unreliable, and wrap their fixes on top of it, often hiding the project.
They’re not wrong (early in, most OSS projects are literally not even 1.0 projects yet!), but it’s rhetorically risky strategy. With the early adopters, you have to show how you make it better and are evolving the project without hiding it. At this stage, you celebrate the complexity as capability, establish your role in the community, and build up skills in the project.
Mid-cycle, you genuinely work with the community to make the overall ecosystem better, making sure to keep decoupled from any existing incumbent technology (that is, rival) as much as possible. This gets complex. You want to have about zero coupling to your rival technology laterally, can sort of freely couple downwards, and maybe do it upwards. Also, the key community marketing you’re doing here is to avoid being accused of skullduggery and taking part in conspiracies to take control of the community.
At some point, all of your big customers will be asking about the technology. Your sales people will start to ask for comparison slides, you’ll find yourself asking talking about how it’s actually mor expensive to use the open source technology because of all the people you’ll need to hire, how long it will take to implement it, etc. ROI cases based on people productivity are often then true and good, but they can also be used for redirection. This stage is when your early work in the open source community, helping it instead of fixing it will pay off.
You’ll have a good reputation, experience, and some reference installs (paid or not!) which will put you on good footing. You do the same thing here: you are making your customer’s use of the project better, not competing with it or telling them that they’re wrong, and should use your better rival.
The thing you do slightly differently with enterprise customers is that you talk about usability, cost controls, security, compliance…basically all the goals of ITIL. You also talk to people who do not actually install, maintain, or use the product. You want to build trust with them - “executives” - that you’re offering is safe and will make it so that the people using it don’t screw or up.
And you have to explain how you fit into every obscure compliance and security scheme, work with older enterprise services, and how you help or hinder various methodologies.The last can be maddening: we do DevOps, how does satisfy those requirements? Does this work with SAFe?
Also, you’ll need to work on-premises and off the Internet (air gapped).
In general, you are never saying that the open source project you’re working on/around is bad, nor that you are fixing it. Instead, you are helping the project grow and become better at accomplish the hopes and dreams of the community. You don’t point out deficiencies, you help make it better. You don’t tell people to use your rival technology, you help remove roadblocks to the customer using the open source project.
All of this doesn’t always apply, but I’ve seen it many, many times. I think kubernetes was the most recently big example (one could say I was on the wrong side of that, so I have some, er, fun insight), and I think Backstage is becoming a smaller example.
What I hear about Backstage is that people are interested in it, not only problems it solves. This nuance is something only a product marketer will understand: you’re not supposed to sell the tool, you’re supposed to sell the solution. Shovels versus holes, and all that. The hole always has better EBITA.
The shovels/holes metaphor breaks down because people in this case actually do want a shovel. It’s like saying I don’t want a steak, I want to not be hungry. So, I should accept a compressed block of mechanically separated chicken parts instead, because that will solve my problem, dig my hole.
The shovel/hole problem is that it’s a misdirection. Mysteriously, the only people who tell you you don’t actually want a shovel are people who are not selling shovels.
This is similar in to the last three or four years of kubernetes conversations I saw (including all those “not a vendor pitch that is totally a vendor pitch” meetings and conference talks). If you didn’t have kubernetes to sell, you challenged your customer’s/audience’s idea that they wanted kubernetes. You didn’t tell them how you could help, you told them why they were wrong, even foolish.
There’s a lot of cleaning up, here, to do for survivor bias. There were many rivals to kubernetes that people wanted to use as well. And…if you had kuberntes to sell, you certainly went around telling people that, for example, Cloud Foundry or Swarm was equally the wrong choice.
The missing part to all this thinking is putting in place a model for identifying the winning open source project and ideas early enough to be a good citizen in that community.
I don’t really know how to do that reliably. I think the answer is: do all the things and go tie out which ones are working this time, and which ones are giving your bad results this time. For example, “pay attention to what the smart people are saying” can be just as good as bad.
Something like the RedMonk programming language tracker is interesting. You could track what customers are asking for.
I suspect that as with most methodologies, models, and strategy advice the answer is annoying: you just need to do the obvious thing, but actually do it and consider it.
This “be nice” thinking goes the other direction too: the new technology is rarely served by putting down the old one. Agile development did a pretty good job of positioning itself as helping people in waterfall processes. As always, there were some iconoclasts who couldn’t help themselves. But overall, that community was nice.
In contrast, the early DevOps community was pretty rude to the ITIL and ticket people. This just slowed things down and reached a bizarre apex in a multi-year spat over “bi-modal IT.”
When you piss backwards, what you don’t realize is that you’re pissing over all the people who are following that “old” methodology or use that old tool. You’re pissing on your future customers!
Some will be glad for it - they are so desperate to escape that they’ll take it, hoping your sass will wake-up to their peers and bosses who don’t want to change. But, everyone is else will just thinking “that asshole just pissed all over me!”
So, the new technology shouldn’t declare the old one dead. That rarely works well when it comes to converting…helping the mainstream.
(Obviously, in aggregate, DevOps has long gotten over this pissing backwards and is more inclusive…indeed, it is now the one getting wet from time to time.)