Check out my review of the DevOps Handbook and Start and Scaling DevOps in the Enterprise over on The New Stack. Unsurprisingly, I liked both of them, esp. the second: What I find so helpful, and even thrilling, about Gruver’s book, is that it’s exacting in its instructions and walks through several what-if scenarios for addressing common problems that come up when applying agile and DevOps at scale. Plus, it’s the perfect size for a book of this type: about 90 pages that’ll take you about 90 minutes to read.

This post is pretty old and possibly out of date. There’s updates on this topic and more in my book, Monolithic Transformation. Every journey begins with a single step, they say. What they don’t tell you is that you need to pick your step wisely. And there’s also step two, and three, and then all the n + 1 steps. Picking your initial project is important because you’ll be learning the ropes of a new way of developing and running software, and hopefully of running your business.

I cut the below montage-y overview of the history of enterprise open source from a Register piece I’m working on. Here it is! For me, the dawn of enterprise open source was somewhere around 2001 when IBM committed billions of dollars to shoring up Linux. Around this same time, the Eclipse Foundation (also launched by IBM) started it’s IDE market re-rigging, and the Apache Web Server was climbing the hill to market dominance piloting the way for the rest of the Apache Software Foundation.

While HPE is getting $2.5bn in cash, the whole deal value is more like $8.8bn, the non-cash being stock. More details: The Numbers “Under the deal, HP Enterprise shareholders are expected to end up with Micro Focus shares currently valued at about $6.3 billion. Micro Focus will pay HP Enterprise $2.5 billion in cash.” (WSJ) There’s about 12,000 people in HPE Software. (WSJ) HPE Software revenue: “HPE’s software unit generated $3.

The Docker forking hoopla is providing an interesting example, in realtime, of how open communities figure out monetization. #RealTalk: Open communities are not immune to C.R.E.A.M. One of the most important decisions an open source community makes is where and how it will make money. I always liked Eclipse’s take because they’re mega clear on this topic; the ASF plays this goofy game where they try really hard to pretend they don’t need to answer the question, which itself is an answer, resulting in only the occasional quagmire; Linux has a weird situation where RedHat figured out This One Cool Trick to circumvent the anti-commercial leanings of the GPL; MySQL has a weird dual licensing model that I still don’t fully grasp the strategic implications of; RIP Sun.

tl;dr Recently, I’ve been in conversations where people throw some doubt on DRY. In the cloud native, microservices mode of operating where independent teams are chugging along, mostly decoupled from other teams, duplicating code and functionality tends to come more naturally, even necessarily. And the benefits of DRY (reuse and reducing bugs/inconstancy from multiple implementation of the same thing), theoretically, no longer are more valuable than the effort put into DRYing off.

Most of what we do as white-collar workers is help our organization come to a decision. What new geographies to sell our enterprise software and toothpaste in, what pricing to make our electric razors and cranes, which people to fire and which to promote, or how much budget is needed according to the new corporate strategy. Even in the most cynical corporate environment, asking questions — and getting answers! — is the best, primary way to set the stage for making a decision.

One of the more eye-rolling tactics of white collar workers is what I call “fence painting”: an employee somehow gets someone else to do work for them. This can be as simple as coasting off budget, but the more insidious practice is to get other outside your chain of command to do work for you. Most of us have experienced this: days after The Big Meeting you suddenly think “why am I up at 11am working on this report for Scopentholler?

In corporate meetings, oftentimes one person figures out a problem and comes up with a solution. Equally often, multiple people in the meeting like the re-iterate the point in their own words, adding 5–10 minutes more to the meeting. Once the epiphany and decision is made, everyone should just close the issue, and move on. No need for people to comment on it more. For example, in one company I worked for we were discussing a software product name.

This post is pretty old and possibly out of date. There’s an updated version of it in my book, Monolithic Transformation. In contrast to the way traditional organizations operate, cloud native enterprises are typically comprised of self-motivated and directed teams. This reduces the amount of time it takes to make decisions, deploy code, and see if the results helped move the needle. More than just focusing on speed of decision making and execution, building up these intrinsically motivatedteams helps spark creativity, fueling innovative thinking.