Today it’s just a links and wastebook clean out.

Two Recent Garbage Chairs on Amsterdam

I’ve found a few Garbage Chairs of Amsterdam recently. Truth be told, I stopped looking. When I moved here, the locals were bemused about all my photos “I never really thought about that,” they’d say, “but; yeah, there are a lot of garbage chairs!” I’ve got to get that sense of wonder back.

(I seem to have deleted wherever I kept the archive of all these. I should set one up again. In the meantime, here are some video commentaries on some Garbage Chairs of Amsterdam.)

From Google Gemini on the above (who knows if it’s true?):

The image you sent me is titled “CAFÉ HAVELAAR” and it was created by Dutch artist Anton Pieck (1895-1987). It is a pen and ink drawing of a man standing outside of a cafe. The man in the image is likely a customer or employee of the cafe.

Pieck is known for his illustrations of fantasy worlds and fairy tales. His work was also inspired by the Art Deco movement and Expressionism. This particular drawing is a realistic depiction of a scene from everyday life.

The CAFÉ HAVELAAR drawing is not one of Pieck’s most famous works, but it is a good example of his skill as a draftsman. The drawing is detailed and atmospheric, and it captures the feeling of a quiet moment on a city street.

I like the phrasing of “not one of his most famous works.”

That feels comforting, like:

“What did you do today?” the man in the well fitting suit standing at the end of my desk asks.

“Oh, you know,” I say raising my eyebrows, smiling lazily, standing as I wipe my hands on my pants, “just finished up not one of my famous works.”

“Ah, very good,” the well-fitted suit man says, “shall we go get a beer?”

wfh, artist edition

From “About my studio”…

(1) No commute saves time and means booting up into work is faster and frequent:

there is also an advantage to not having a separate studio outside your home. When I did rent a studio in the past it meant that all my artwork in progress was elsewhere, and that required overcoming inertia to make myself go to my studio. When the artwork is right next to me then it’s simple to do a few minutes extra work on it – correcting a mistake or enhancing a part of the image – without needing to trek to the studio.

(2) You think about work more frequently, a good version of living rent free in your mind…work lives rent free in your house? But, it’s your work, living in your head, not The Man’s work.

And having my work-in-progress continuously visible out of the corner of my eye while I’m decompressing from my day job – streaming a film, reading a book, browsing the web – means that I unconsciously reflect on it during my downtime, allowing flashes of lateral insight to spark in my head while I’m actually concentrating on something else.

These more apply to solitary synchronized, creative endeavors. When it comes to synchronized collaborative management (“meetings”), maybe not so much?

Relevant to your interests

• Au petit Cordon Bleu - Fun, 1930’s cookbook.

• The Ultimate Guide to building Developer Tool Websites - PLG for developers. Get them home pages set-up for the funnel!

• Automation and the Jevons paradox - Always good to bring in Jevon’s Paradox.

• UHF in UHD: Weird Al’s cult classic movie will get its first 4K release - “Nothing says ‘I love you’ like a spatula.'” // this movie, and the VHS of Pee Wee Herman’s stage show are probably the basis of my humor. Many summers watching stand-up and Doctor Katz on the Comedy Channel came later, but were probably equally defining. And, of course, the Phil Hartman era of SNL, and the occasional Letterman when I stayed up that late.

Wastebook

• “Just realized French Onion Soup without enough broth is a soggy onion sandwich.” Galaxy brain level shit from Matt Ray.

• “It’s really a celebration of personal freedom and surplus wealth.” Here.

• And: “huffing the fumes of Timothy Leery’s corpse, or whatever.” Ibid.

• “Yeah, in France they don’t have refillable drinks but you can buy cigarettes instead of fries.” Here.

• “The result often reveals the unconscious clichés of the users.” Here.

• “Coffee badging” Here.

• “What I didn’t know about Battersea is that the lower-level floors are a mall, with Apple’s offices taking up the higher floors.” Here. // This is something I really like about London: all these hidden away nooks and crannies, sometimes whole malls! You can see how Neil Gaiman could have come up the “London Below.”

• “slop” - spam/AI generated copy and images.

• Sometimes you’re at a trade show after party, and someone with a camera and fancy mics is like, “hey, want to record a little interview?” You want to say yes, because what the fuck else are you doing at that after party? Here is an example of two masters at work, delivering the perfect pitch for that moment (clear explanation of the problem solved, clear explanation of the product/solution, check out the 2 unnamed customer references, the one named reference, name-check the VC investment, giving a tiny briefing on the state of the company [which only an analyst would care about, but which is important to drive thought leadership, buzz, and story], a notice very little filler words and stammering, mention of TAM, etc., etc.), relaxed, keeping the answers short, pedigree of the CEO (themselves). Also, the interviewer, Dave, is good too: look at all those takes and survey numbers he can weave in there. All in 9 minutes and 26 seconds. (I’ve known Aaron for a long time, so I may be a bit biased.

• The past is only in the present if you think about it. #DadTalk!

• Another day, another Euro.

• Can you imagine there being an answer that would be helpful? If not, don’t bother to ask the question. The question you’re thinking of is probably more of a statement.

• “disadvantation” Context.

Have you had a chance to check out my series of videos full of my advice for working in a large company? WHAT?! If you have access to O’Reilly’s stuff, you can watch these. If you work at a large company, there’s a good chance you have access. Anyhow, check them out. There’s four five star reviews our of five reviews, including these accolades:

That’s right. Watch em!

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

There’s more school holiday the rest of this week, if you can believe it. I have to tell you: these Europeans might be on to something.

About my studio - Working from home, artist edition. (1) no commute saves time and means booting up into work is faster and frequent: “there is also an advantage to not having a separate studio outside your home. When I did rent a studio in the past it meant that all my artwork in progress was elsewhere, and that required overcoming inertia to make myself go to my studio. When the artwork is right next to me then it’s simple to do a few minutes extra work on it – correcting a mistake or enhancing a part of the image – without needing to trek to the studio.” (2) you think about work more frequently, a good version of living rent free in your mind…work lives rent free in your house? “And having my work-in-progress continuously visible out of the corner of my eye while I’m decompressing from my day job – streaming a film, reading a book, browsing the web – means that I unconsciously reflect on it during my downtime, allowing flashes of lateral insight to spark in my head while I’m actually concentrating on something else.” // These more apply to solitary synchronized, creative endeavors. When it comes to synchronized collaborative management (“meetings”), maybe not so much.

UHF in UHD: Weird Al’s cult classic movie will get its first 4K release - “Nothing says ‘I love you’ like a spatula.'” // this movie, and the VHS of Pee Wee Herman’s stage show are probably the basis of my humor, at first. Many summers watching stand-up and Doctor Katz on the Comedy Channel came later, but we’re probably equally defining. And, of course, the Phil Hartman era of SNL and the occasional Letterman when I stayed up that late.

The Ultimate Guide to building Developer Tool Websites - PLG for developers. Get them home pages set-up for the funnel!

When it comes to cloud native application platforms, we’re at an important evolutionary point: will the best practice for platform strategies be to build or to buy? Should you choose the components you need for a platform and integrate them together, or should you buy a pre-integrated platform? Unless you’re a handful of organizations, the practical answer is that you should buy the platform.

Before I get to why, what even is a “cloud native platform”?

Defining a cloud native platform

The Platforms Working Group at the Cloud Native Computing Foundation (CNCF) has a great paper defining “platform.” They’ve got a real swell burger-diagram, above. Trying their best to boil down 13 pages into one paragraph, the authors summarize a platform as:

Platforms curate and present foundational capabilities, frameworks, and experiences to facilitate and accelerate the work of internal customers such as application developers, data scientists, and information workers… A platform for cloud-native computing is an integrated collection of capabilities defined and presented according to the needs of the platform’s users. It is a cross-cutting layer that ensures a consistent experience for acquiring and integrating typical capabilities and services for a broad set of applications and use cases. A good platform provides consistent user experiences for using and managing its capabilities and services, such as Web portals, project templates, and self-service APIs.

Platforms support the software you’ve built to run your business. A platform not only runs that software, but it manages the services your apps need. Typically, the platform also specifies how your apps are packaged, configured, and deployed to your platform. The platform usually has opinions about your app’s architecture. For example, a cloud native platform really wants your apps to follow the 12-factor best practices and use a microservices architecture. You know: containers.

Avoid accidental platforms

Platforms are the interface between your application developers and the cloud infrastructure and services their apps use. To me, that’s the key thing that makes it a platform instead of just a pile of clouds or catalogs full of “services” that developers have to find, learn, and integrate into their applications.

All apps need a platform to run. Developers will create that platform if one doesn’t exist. This leads to the spread of “accidental platforms” across the organization. All of these platforms need to be managed and cared for, and since they’re all different, staff spend a lot of time managing each platform.

In a large organization with thousands of developers and applications, teams don’t get the benefits of scale when they have a bunch of different platforms. This creates a huge amount of drag on IT: an IT manager, for example, and his staff could end up spending between 70% and 80% of their time on maintenance just keeping all the platforms running, with little time left over to improve those platforms or add new functionality developers need.

The main issue here is that it drags down the actual business because an organization’s apps are increasingly how the business functions, and even what the business is to customers. Think about how people interact with businesses, government agencies, schools, and even their hobbies and entertainment. Most of that is done through an app, through software as the primary, if not mission critical, component and “storefront.” And it’s not only that, software is how businesses get better, grow, and innovate.

Is Kubernetes a platform?

Over the past few years, there’s been a lot of confusion about where the line between a platform and infrastructure is, mostly driven by everyone’s interest in Kubernetes. Kubernetes is more focused on standardizing how infrastructure is used and managed, and how apps are configured and run.

That standardization is the goal of Kubernetes: wrapping an industry-standard API around all the different cloud infrastructures. It’s removing variability, which is always good in large IT shops. But, as said long ago, Kubernetes is a platform for building platforms. You use it to standardize your infrastructure across clouds, across on-premises, and even “edge,” so that you can then build your application-focused platform. On its own, Kubernetes just delivers a blinking cursor: an empty cloud that’s ready to be filled with useful services and apps.

But if you stop there, things go poorly. Many organizations are much too quick to hand over that blinking cursor to developer teams who have to first understand how Kubernetes works, and then, second, build the platform they need on top of Kubernetes. The result is a backslide into a mess of accidental platforms.

So, is Kubernetes a platform? Not the kind we’re talking about here, a platform for application developers. It’s the foundation for a platform. You still need to add the services, interfaces, and tools that application developers use. There are also all the usual operations, security, and compliance services you need.1

Pitfalls to building a platform

This is all to say that if you’re building a platform, you have a lot of work to do. You need to select each of the components, integrate them together, keep them updated, and improve them as you learn what works and doesn’t. In short, you now “own” a full product, including supporting it. And you need to run it and manage it. Ongoing, as new capabilities come along you’ll need to add those into your platform, for example, AI, new versions of programming languages and UI frameworks, databases, and so forth.

This is a lot of work. There used to be a quip that “all companies are software companies now.” which always seemed weird to me. No matter how good at software my favorite fried chicken restaurant is, if I order some Korean fried chicken, I want to find some fried chicken and fried cauliflower in the box, not software. But, once you start building your own platform, then you are a software company with the responsibility to build and maintain a software product. That requires a lot of corporate resources like time, money, and attention.

Whether your business is fast food, insurance, manufacturing cars, collecting taxes, or whatever else, you’d probably rather spend time being good at your business than good at platform building.

Benefits of buying a platform

For most organizations, a platform contributes very little to a business’ differentiation. You need a platform, but like electricity, email, ERP systems, and even analytics, the platform itself isn’t what makes a difference. What makes a difference is what you do with the platform and how you use the platform. The more time you spend building and maintaining your own, homegrown platform, the less time you spend focused on your actual differentiation, including your applications.

So, unless your customers buy from you because of your unique platform, you should probably buy your platform instead of building it. This frees up your resources to focus on your actual competitive advantages. '

Things like: how do they get that cauliflower so crispy and keep it so crispy as it cools off on the bike trip to my house?

You’ll also benefit from the platform being an actual, evolving product. For example, at the Tanzu, we build a platform, and we spend all of our time adding new features, improving it, and integrating it with as many types of infrastructure and services as possible.

The feature-set isn’t static like so many homemade platforms in large organizations end up being. You can see this with the AI services we’re adding to the Tanzu Platform – that’s become a priority for many organizations, so we’ve been adding it to our platform. The comprehensive integration with the Spring Framework is another example. If you have enterprise applications, you likely have many Java applications, and if you have Java applications, you’re very likely using a lot of Spring. If you use the Tanzu Platform, you can update your Spring apps quickly and easily, benefiting not only from new features in Spring and Java but also getting the performance and cost savings improvements.

What that means is that you have more time to focus on what actually matters: your own software and applications. That’s enough work, and hard enough, without having to worry about how you configure and deploy software, manage security, handle data, and otherwise do all that stuff below your apps.

To the question of whether it’s ultimately better to build or buy: buying a platform means you can focus all of your effort and resources on making your business better by perfecting how you make your software.

If you’re interested in how a platform fits into improving how your organization builds and runs software, check out the discussion below I had on that topic with Purnima Padmanabhan and James Watters. We of course talk about the VMware Tanzu platform, but you’ll also hear how large organizations are thinking through this build/buy decision.

This was originally published on CIO.com as a VMware Tanzu sponsored post (“BrandPost” they calls it). But, don’t worry, I did actually write it, all by myselves! Well, I mean, with some suggestions and copyediting from my work-pals, sure. I made some slight changes in the above.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY. And, if you register for SpringOne/VMware Explore before June 11th, you’ll get $400 off.

🪵 Logoff

That’s it for today. I’ll save up the fun links and strange things from the World Wide Web for tomorrow.

Automation and the Jevons paradox - Always good to bring in Jevon’s Paradox.

Today’s survey: “State of the Developer Experience 2024,” Harness/Wakefield Research.

Most enterprises need to automate their build and deployment pipelines. This is more than just building code and automating tests (which 71% of people are not doing), but also automating governance and security checks (which 41% of developers are not doing).

In my mind, this is the number one thing development organizations should be working on in 2024, and probably next year. Any ambitions to migrate to cloud, put Kubernetes in place, help software eat the world, etc. are going to go poorly if you don’t have an automated build.

Just automating your build will have large, positive benefits and ROI. Automating your build will give you a massive boost in productivity, meeting deadlines, meeting compliance and securing your apps, and raising employee morale.

A cynical(?) take on this is to say that the real magic of any “platform” or “cloud native” technology is that it requires you to automate your build pipeline1 and that automating the build pipeline is where the majority of improvements come from. Whether you’re running your apps on VMs, Kubernetes, Cloud Foundry, a shell-script platform, or a bunch of raspberry pies duct-taped together, as long as the build pipeline is automated, you’re going to improve.

Let’s look at a recent developer experience survey that gives us more numbers to pile on that fire, the Harness “State of the Developer Experience 2024” survey.

Slow onboarding, slow releases, slow governance & security

• There’s very little demographics-wise, just that it was “500 engineering leaders and practitioners.” It was done with Wakefield Research.

• Developer onboarding time is a major focus, see below for longer discussion.

• “62% of executive buyers would prefer a platform versus siloed tools.” // I assume this means a centralized/standardized platform versus a bunch of platforms in silos, and then just tools that are not even integrated into a platform.

• “60% of organizations are still releasing code on a monthly or quarterly basis.” // In the 2024 CD Foundation survey, 40% of respondents said “less frequently than a month,” 31% said “once per a week to once per month.” Let’s take 10% from that 31% as “once a month,” and throw it together with that 40%, to get a delicious kapsalon of 50%. So, while the CD Foundation doesn’t capture “a month or more,” in the realm of sponsored surveys, the numbers are similar enough to be in the same ballpark.

• “67% of developers have attested to waiting over a week to complete code reviews.” And: “59% say that their AppSec requirements limit their ability to release code frequently.” // These isn’t the best proxy for bad bureaucracy, but they’re probably representative of governance bottlenecks. Now, if you got sloppy with code and security reviews, and something went bad in production, you’d probably be all for bottlenecking. And, in fact, that probably happened several times and it’s why you have those code review and security bottlenecks.

• But: “40% of developers admitted that their organizations don’t enforce good security and governance policies across the lifecycle.” // Optimistic case: that’s because they need to automate and standardize how security is done, which is now done manually, driving 59% of developers to say that security requirements slow down their release frequency. And, indeed: “41% of developers don’t have automated security and governance policies”…I assume that means “in place.”2

• These code and security review bottleneck figures are a good pairing with paired programming which has an implicit code review built in, more or less.

• Human stuff: “52% of developers cited burnout as a reason their developer peers leave their job.” And: “As evidence, 45% of developers surveyed say they don’t have enough time for learning and development. And executives seem to agree.”

• Global developer population estimate: “developers, estimated at around 30 million globally.” // This number is a lot harder to pin down than you’d think, so it’s always nice to see someone take a go.

Onboarding

“It would take a new developer 100 days to onboard, considering the multitude of tools involved.” Meanwhile, the executive perception is that it’s 40% faster: “71% of of executive buyers said that onboarding new developers takes at least 2 months [60 days].” It’s always fun to find differing perceptions between management and workers. Most of the mismatches are like this, with the management thinking things are better.

Solving this onboarding problem was the reason Spotify made Backstage, I think. That’s lingered in the platform engineering community ever since, though I see it a lot less now-a-days.

Relative to other problems, I’m not sure enterprises care that much about developer onboarding. It’s sort of a one time problem per developer. In tech companies, there’s high churn for developers, so you want to onboard people quickly to replace developers who’ve left, but also scale-up your efforts by hiring new developers as you write new code to add new features to grow revenue (or, eyeballs - whatever) and to get into new markets with new apps.

But I suspect that in not-tech enterprises, the churn is less. And, post-ZIRP/whatever, with the miasma of industry layoffs still lingering, I’d wager most buyers are less concerned with that. “What? Are they going to be able to find a new job? Back into the coal mines!”

STILL! It’s still a good tracer for software hygiene. One thing that’s overlooked in onboarding bottlenecks is the effect slow onboarding has on maintenance and bug fixing. When you go to fix a bug in production, you have to set aside the yet-to-be-released version of the app you’re working on, and go back and setup the old version of the code.

This means, basically, onboarding to the project again (OK, not all of it, but probably the majority of it), which is time consuming. So much so that many developers will keep those old versions all pre-installed and ready to debug and patch sitting around somewhere.

The business case for the elusive platform buyer

Marketing wise, they’re doing the “show ROI by increasing developer productivity” thing. This is a fine sales tool. Some clever sales engineer will create a spreadsheet of it, and you’re off to the races! Give it to an inside sales rep, and you’ve got some great email threads goin'. There’s always the dream of doing a self-service workflow where people fill this out themselves, see some cool bouncing charts, and then get asked if they want to talk with an ISR. (Does that actually ever work, though?)

That sells the idea of the problem you’re solving. What you have to marry that kind of ROI model with is showing that cheaper-to-free alternatives (“the developers say they can get Backstage up and running on their own…”) will not get you the same result. In that way, an ROI pitch like this is great for introducing a new idea and market category (here, platforms/IDPs) because you’re just trying to convince people that it’s a problem they have with a known solution.

You can also see who these ROI pitches appeal to because they’re using a base of 1,000 developers in the calculations. That’s a pretty big company, which is fine. They’re the ones you want to sell centralized developer tools to. A larger company has bigger budgets and it’s a lot cheaper to sell to one group than a bunch of dev teams.

Nowadays, finding the platform customer that also has budget is tough. The VP of AppDev has little budget, but they have the need. And, of course, they have tons of app developers who are like “oh, I could do that in a weekend.” The VP of Infrastructure has tons of budget, but they don’t care about apps (usually by design and comp)…and the app people don’t want them to care. You can go to Line of Business people (“The Business”), but that’s not easy either, pretty much impossible.

That misalignment is one of the reasons there’s so much platform sprawl, and why you need to do this kind of ROI’ing. You’re trying to go against the very structure of the IT organization. You know, change the “culture.”

Selling a centralized platform is tough!3

Work smarter but keep working harder

Here, let me find my Marx hat to put on.

ROI is a way of showing buyers that your software is worth paying for. It makes your developers work faster, and therefore they can hit deadlines better, software eats the world, number go up, BUSINESS, BUSINESS, BUSINESS!

Abd then, you can have the workers do more work for the same pay! More work with the same. Buy low, sell high.

This is why “productivity” can be a let-down for workers. Better productivity should mean that you can go home early, work less. But, nope: you keep working.

A worker might be motivated to increase productivity to prevent (1) overtime (in the survey 23% of developers said they work overtime at least 10 days a month), and/or, (2) boredom and tedium.

These are great things for a worker to strive for! However, management has to make sure to actually keep those benefits in place. As you get more productive, management tends to want to do more and tackle on more complex things. The Share Price isn’t content with flat, reliable EBITA.

If the workers suddenly have free time, get them to do more work! Eventually, you’re back to working more overtime and introducing back in the tedium. “Now we need to figure out how to leverage AI! Oh, and what’s your sandwich order for tonight?”

Progress! The cycle continues.

For workers, the productivity metrics to track are (1) going home on time (2) eventually, going home early, (3) reducing bullshit work that could be automated or just eliminated entirely (“toil”), (4) more pay and benefits.

We should make a Backstage plugin for those.

Definitions

Finally, the survey has some good, concise definitions of common terms:

• Toil: “Developer toil can be characterized by repetitive, manual, and low- value tasks that consume significant time and effort.”

• Goals of DevOps: “The overarching goal of DevOps is to foster collaboration, automation, and a continuous delivery pipeline that enables organizations to rapidly and reliably release high-quality software products and services.”

Reader letters

Jay Cuthrell sends the following re: yesterday’s ketchup taboos talk:

Two spouts - way to increase productivty, eh?

Check out his newsletter, if you like this one, you’ll probably like that one.

Relative to your interests

• Before Platform Engineering Killed DevOps, SRE Killed DevOps.

• That time when Microsoft bought and killed Nokia phone unit - Good write-up of (probably mostly) forgotten time. // “Barely two years after it was announced, the whole thing fell apart and Microsoft wrote the whole thing off as a tax loss.” And: “Elop was right, but his solution wasn’t.” // “Disruption” is an easy word to say, but a very difficult one to solve. // And a D&D reference! “The Nokia board rolled the dice again on hiring another non-Suomi manager, Rajeev Suri, and this time hit a double D20 in D&D terms.” (Though, I’ve never heard of a “double d20,” but, sure, probably.)

• If you didn’t find it in the links above, this documentary on waste and burnout in corporate work is great. You’t thinking “that’s an hour, WTF?” But, really, just watch it, it’s good.

Wastebook

• "A certain amount of uncertainty." Here.

• “Today, a fathom equals six feet–quite an inconvenient number to use in your head, when trying to go back and forth between feet and fathoms.” // For some of us, all numbers are “quite and in convent number to use in your head.” Here.

• “refusenik” bruces.

• “pluralistic ignorance.” Yup.

• And: “I really felt that part when the lawyer said she wanted to get hit by a car just so that she wouldn’t go to work. Feel that most days, if not all.” Comment on Ibid.

Conferences, Events, etc.

Talks I’m giving, places I’ll be, and other plans.

Atlanta Executive Dinner on Enterprise Software Dev, etc., May 22nd. DevOpsDays Amsterdam, June 20th, speaking. NDC Oslo, speaking, June 12th. SpringOne/VMware Explore US, August 26–29, 2024. SREday London 2024, September 19th to 20th.

Discounts. Cloud Foundry Day (May 15th): 20% off with the code CFNA24VMW20. SREDay London (Sep 19th to 20th) when you 20% off with the code SRE20DAY.

🪵 Logoff

I saw an early summary of a platform survey we just did. It has some good figures in there. I’m interested in sharing the platform sprawl related ones.

That time when Microsoft bought and killed Nokia phone unit - “Barely two years after it was announced, the whole thing fell apart and Microsoft wrote the whole thing off as a tax loss.” And: “Elop was right, but his solution wasn’t.” // “Disruption” is an easy word to say, but a very difficult one to solve. // And a D&D reference! “The Nokia board rolled the dice again on hiring another non-Suomi manager, Rajeev Suri, and this time hit a double D20 in D&D terms.” (Though, I’ve never heard of a “double d20,” but, sure, probably.)

Business models are fascinating. Most business models come down to a type of arbitrage, at least as I understand it. You find something you have that you can sell to someone else, crucially, at a price above what it cost you to make that thing.1 In, let’s call it, The Capatalist Upbrining, there is a major intellectual jump where you understand that the price for a think is not determined by what it cost to make it, the costs of goods sold. No, no - not at all. How much it cost to make a thing has little to do with what price the thing sells for. And there’s the arbitrage: a business model is all about making the difference between the cost of goods sold and the price paid for goods as big, large, and mysterious as possible. Buy low, sell high.

It is because I am so familiar with the business of software that I think of it as The Beautiful Game of business. There is only one product more ephemeral as software, and that’s selling identity, life-style, existential, I don’t know, “affirmation”: Coke, Nike, Patagonia. The margins on selling identity are extremely high and durable over decades. But, software is up there.

Anyhow, this is why connoisseurs of software strategy are annoyingly obsessed with open source startups and business models. It’s like my imagination of studying particle physics: you just load up some stuff into a big torus, wham that stuff together at high-speed to make them explore real good, and look at sparks and charts that follow.

Anyhow, that’s the subject of this week’s Software Defined Talk episode. The theory I put further is that open source is a commoditize your condiments business model. Which is to say, it’s ketchup. You can’t have a business that just giving away ketchup.

You would never eat ketchup on its own: this is widely considered disgusting. Put in your mind the image of someone walking up to a ketchup pump, bending down, putting their open mouth under the spigot, and giving one, swift pump.

Buuuuut: if you put ketchup on something, it is considered delicious. American French fries are not very good on their own: you pay for them as an excuse to eat ketchup.

An open source business without the fries performs poorly.2

There is no free-as-in-catsup in Europe

When it comes to the business of condiments, the Europeans are the clever ones. Usually it’s the Americans who are clever at the business of software, pardon, I mean, of condiments. First, the Europeans eat mayonnaise not catsup. I think they view catsup as something like children’s food, but I’ve never really asked.3 Back to my point: the Europeans never made mayonnaise free. You pay for mayonnaise and catsup. You pay an insulting amount: something 50, sometimes even 80 cents. It is insulting because it is such a small amount.4 Well, insulting to Americans.

In America, pricing obfuscation is politeness. A business should not reveal that it uses “loss leaders” as a net to pull in fish; a business should never let you look behind the curtains and see that they’re selling sugar(free) water at a massive mark-up. The ketchup you get from pumps and packets at an American restaurant isn’t free, the price is included in everything else.

But in Europe, no.

They make you know the price everything you’re buying. Europeans are very open, clear, straight forward, explicit. Transparent.5 They want you to know exactly what is happening, exactly the truth. Everything is catalogued, everything is logged. Do you want catsup with your burger, then, here, I am putting that on the receipt, what you paid for it. Are you behaving in a strange way? Then, here, I am going to tell you. Surely you must know this, and if you don’t surely you will be delighted that I am telling you

Americans have a phrase, “not my circus, not my monkey.” The European equivalent would be something like “our monkey, our circus.”6

Hmmm. I seem to have doorway’ed myself here.

So.

Anyhow! Check out this week’s episode, The Big Blue Burger Buffet.

📼 Lead Time to Schwag

The first thing that’s funny about this talk is that the people who posted it didn’t realize I completely changed the talk. They posted it with the original title. I mean, obviously they weren’t going to watch it, but it’s such a strange editorial non-decision decision.

The second funny thing is, you know, my actual talk. How do you apply developer productivity metrics philosophy (you know, “developer productivity”) to getting free shit at a conference? Also, who doesn’t like a good ITILv3 joke? I didn’t watch it until the end, but who does that in YouTube?

🪵 Logoff

Back to work tomorrow!

On that random person in Nebraska

1. Open source is important for the entire industry, sell side (especially in the cloud era) and buy side. Things would go very bad if it did not exist as method of software production and innovation. (Source: see the QED from that one xkcd.)

2. Open source is a bad business model, it’s very difficult to grow and it conflicts with the VC need for a big pay off. (Sources: The pro-business license changes at open source companies in recent years [too many to cite]; many more; most recently well put by Brian Gracely in his Cloud Sunday Sermon.)

3. VC funding of open source companies is not a great area for returns (versus other opportunities). VCs should fund closed source (at best, open core) software (and cloud) companies. (Source: while Aneel never says this in words, in the room, it felt like he was saying it with sighs.)

4. Open source is only sustainable when part of a big company that makes money because open source if a commodified compliment of their closed source/cloud product. (Source: Kubernetes; us in this week’s Software Defined Talk episode.)

5. Open source is a generational (young boomers and Gen-X) variance that got its last gasp from ZIRP. With cloud and SaaS, there’s little reason to do open source as a business, plus, see #2 above. I like this observation because it shows the bias my generation has to open source as a good business model (and, thus, many of the major thought-leaders, just by age and aggregation of attention over the years, e.g, still being alive). (Sources: Red Hat was always held as the proof of this view, but even they are no longer independent; The Oxide podcast episode on FUD; Pete Cheslock’s DevOps hangover talk.)

6. Open source is a great business model. (Source[s]: I’m looking for some references; awaiting the sogrady missive).

These are collected from my fellow grumpy old tech men RSS feeds. I need to gather views from other RSS feeds too. I reckon there’s probably some good stuff from the recent Open Source Summit.

Sustainability

What comes out in many of the views above, and what I conclude, is that our focus should no longer be on open source business models, but on open source sustainability models.

“Sustainability” means that you can rely on the software existing, being supported (at least patching bugs and, especially, security problems), and preferably evolved and innovated.

Also, I suspect that a kind of unspoken part of sustainability is “free,” but that gets the goat of many of my generation of open source people. In my experience, when you talk with the buy side, they want “free, as in don’t give me a lecture.”

Open Source Foundations: More Important Than Ever

No matter which view(s) is useful (accuracy is always cool, too), I think it shows the importance of open source foundations. They’re even more important now because they (more or less) are not at the whims of either VCsPE needing a 100x cash-out and mucking with the business models once founders [lose|give up] control and slow growth, nor PE companies doing their [MUCH_LESS]x synergizing and optimizing.

The foundations need to be there as long-term stewards, protectors, and community/marketing management for the products. For example, when that xkcd situation happens, the foundations should be hiring that random person in Nebraska: tracking them as an important, strategic asset for the overall ecosystem that needs to be supported, if not by a mega-company, then by the foundation. I don’t know, you could, like, ask The AI to go look at GitHub and LinkedIn to figure that out, right?

The foundations should also be a common ground and (I can’t think of the positive version of this) bureaucracy1 for maintaining the governance in the community. You know: using transparency to enable potential shame to prevent shenanigans.2

Relative to your interests

• Is there a business model in “hey guys” videos for enterprise IT buyers? I replied with some two-coffees-in thinking.

• Supercharged Developer Portals - Spotify Engineering : Spotify Engineering - Spotify is really going for the enterprise product thing! Most importantly, check out the legacy of the Drunk & Retired podcast with The Frontside mention.

• Generated images for non-generated text and video - ‘It’s only a matter of time until “generative art = spammy bullshit” will be the majority position because that’s how the economics of it are playing out. Using extruded synthetic art will not do your writing or video any favours in the long run.’ // I mean, yes, and…the idea is that in the future, the AI generated images will be so good that you won’t be able to tell. But, that is just an ideas.

• A Letter from Paul Auster - When the rejection is more comforting than the confirmation.

• Volo’s Culinary Guide to Icewind Dale - We talk a lot about the downside of the Internet, the web, whatever. But the existence of this as a widely available thing is an example of why the Internet is great. I mean: when would this ever exist otherwise except as some obscure zine on a magazine rack at rundown university coffee shop?

• Java 17 is now the favorite brew of developers, along with - “About a tenth (9 percent) of applications were using Java 17 in production in 2023, and now 35 percent of applications are using Java 17, representing a nearly 300 percent growth rate in one year. It took years for Java 11 to reach anywhere near that level.” And: “While Oracle retained the top spot in 2022 (34 percent), it slipped to 29 percent in 2023, and it’s now at 21 percent – which represents a 28 percent decrease in one year.” // Sure, but what matters more is: is Oracle making more money off Java or less?

• Related: The Java migration imperative: Why your business should upgrade now.

• AWS hits $100 billion revenue run rate, expands margins - (Covered more extensively in this week’s Software Defined Talk.) “The CEO also noted that 85 percent of current IT spend is for on-prem tech. So AWS has plenty of room for growth even as it approaches $100 billion annual revenue.” (1) we’re out of the first inning of cloud, and now into the second inning, the “15% inning of cloud.” (2) selling investors on TAM is dicey. What you’re saying is that the buyers are going to be spending the same (inflation adjusted, I guess), so there will be no price discounts. Counter-argument to (2): the spend will be the same, but buyers will do more/get more: “more with the same.” But, their overall IT budget will remain. I guess that’s macroeconomic “productivity”?

• Generational Shift - When I was growing up, we watched cartoons from our grandparents, parents, and ours times. We had Groucho Marx references in Bugs Bunny. We watched Scooby Doo and Power Rangers. AND WE LOVED IT. I don’t know of if this is good or bad, it just is. It reminds me of what you see on Europe: kids and old people both know the beer garden drinking songs.

Wastebook

• “Someone who knows English never would have thought of that name!” Here.

• And: “Ivy is not a momentary trend that you follow, but a tradition to be honored, passed down from your fathers and grandfathers. It’s not just clothing but a way of life.” Ibid.

• “Welcome to the dematerialization age.” Here (Notice the .do URL - Struts!).

• I know I’m all like “welcome the party” status on this, but Adam Savage! He’s got something special and interesting going on. How does someone end up like that? (Also, notice that he rarely uses filler words like “uh” or “like.” Instead, I think, he pauses to think…and the editors [is it him?] leave the dead air in! Revolutionary!)

• Related: If most people are not experts, most people don’t know how an expert will do something and will be interested. Furthermore, experts are generally older and know “everything.” They are interested in learning more esoteric, unique things. The market for experts is very small compared to the market for everyone else. Therefore, for a broadcast medium like YouTube, you probably want to appeal to beginners who are learning, intermediate level people less, and experts the least. (This likely creates a un-virtuous cycle: in a medium like YouTube, there is less content for experts, so experts start thinking “I don’t ever find anything useful there,” so they stop looking there…at least for things in their area of expertise.)

• The point is not to get there quickly, it’s to get home late.

• “The shape of the conflict with no details.” Matt Ray.

• There should be a version of D&D where the “lite” monsters are removed, and it’s just the big ones. E.g., no more Spectator, just Beholders.

🪵 Logoff

Still on stay-cation; which is to say, I’m sure I have typos and copy-regerts in the above, apologies.

See you next week.