Archive for software trends

Slicing GitOps Baloney Thin

During much of my tech career, I dealt in precision. Precision tolerances for hardware products. Precise specifications for software. marketing language that favored exactitude.

Oh wait. That last one is not entirely true. In fact, even in technical marketing where precise language would seem to be appreciated, vague and even obtuse language is often rewarded. This drives plausible deniability which, in turn, benefits companies when products don’t work as advertised. It’s true across all products, even IT ones. More importantly, it allows marketers to set their products apart from otherwise similar ones.

That brings me to my latest pet peeve – the term GitOps. This particular rant started on Mastodon after a tech journalist I respect a lot (one of the few that grok the technical stuff) wrote an article referencing the term. The article was, as usual, excellent. The title, however, lit my fuse about GitOps.

My complaint is that GitOps is just another name for Continuous Integration (CI) or maybe Continuous Integration/Continuous Deployment(CI/CD). To be more charitable, it was CI using some variant of the open source git (and yes it’s lower case) project. GitOps is, in my opinion, an example of slicing the baloney too thin. So thin, in fact that it becomes meaningless.

At that point, one of the maintainers of the OpenGitOps project, Roberth Strand,  pointed me at the project’s website. I appreciate that, by the way. It’s always a sign of good community when members suggest resources to each other. Mr. Strand especially wanted me to look at the the guiding principles of GitOps. They are 1 :

  • Declarative – A system managed by GitOps must have its desired state expressed declaratively.
  • Versioned and Immutable – Desired state is stored in a way that enforces immutability, versioning and retains a complete version history.
  • Pulled Automatically – Software agents automatically pull the desired state declarations from the source.
  • Continuously Reconciled – Software agents continuously observe actual system state and attempt to apply the desired state.

What you may notice is lacking is any mention of git itself. That’s right, GitOps doesn’t require git at all. Why call it GitOps then? Weird, right?

The other thing that is immediately noticeable is that these principles would apply to most CI systems. Granted some are not driven by declarative languages, but I would argue most are. Ultimately this looks like a specific implementation of CI.

Back to our baloney. This is an example of trying to create an entire category – be it software, product, or community – from a specific case of an existing term. It’s good marketing. Afraid you might drown in the growing sea of CI/CD products, projects, and companies? Narrow the scope and call it something else. Now whatever you are doing sounds new and fresh. Yay!

The downside is, of course, confusion. It walks like a duck, quacks like a duck, but everyone is told it’s not a duck. Instead, consumers (IT pros in this case) are told to believe that a Mallard is different from a duck. The proliferation of technical terms that mean almost the same thing or that are just subsets of subsets makes decision making much harder. Consumers have to spend too much time just figuring out the starting point.

I suspect that enough companies and organizations such as the CNCF have taken up the term GitOps that it is here to stay. There’s no turning back. What is important is that GitOps not be seen as anything more than a specific case of CI, which is only part of the CI/CD pipeline landscape. Ignore the marketing and look under the covers. You might need some CI software or processes, and they may be called GitOps. You don’t need both and they are not competing with each other, except for the marketing.


  1. Source: OpenGitOps,

Why I like Mastodon Better Than Twitter

I know; It’s been awhile. Instead of writing about technology, I’ve been writing about new popular music. I still love technology but writing about music is more rewarding. You can check out my blog at Tunes Past To Present. There you will find reviews about new music that appeals to an… let’s say more mature… audience. 

That’s not what this blog is about. It is about Mastodon and why it’s so much better than TWITer… I mean Twitter. For those who are unfamiliar with Mastodon, it is a microblogging platform that is, in some ways, similar to Twitter. Unlike Facebook or LinkedIn, you can have one way connections with people. With Mastodon, you can follow individuals and see what they are posting, just like Twitter. That’s where the similarities end.

So, here are my 7 reasons why Mastodon is better than Twitter.

  1. Mastodon’s architecture is quite different and better. Twitter, LinkedIn, and Facebook are all centralized services. Even though the underlying systems are no longer monolithic, the service itself is. That’s why someone like Elon Musk can trash it in a few weeks. Mastodon, on the other hand, is a set of federated servers. Each server instance is created and managed individually by different groups of people. It’s like having your own little Twitter. Even if one server goes away, all the other ones would remain. There is no central service to destroy.
  2. Traffic is federated. Posts from one server can be accessed from the other servers in the loosely connected system of systems using a messaging protocol called ActivityPub. You can even connect to different services that are based on ActivityPub. Practically, that means if you can follow someone on a server different from your own. It’s like seeing posts from Facebook and Twitter on each other’s platform.
  3. Focused viewing of posts. On Twitter (or many other social networks) you can only see what you follow. On Mastodon, you can see posts from people you follow, the posts on your local server (i.e. your immediate community), and posts from other connected, or federated, servers. You don’t see them all in one stream like Twitter; You see them broken into those three groups. The upshot is that it’s easier to discover more interesting people to follow than it is on Twitter.
  4. No advertising. Mastodon is run by individuals and some not-for-profits. No one is selling advertising. It’s pure community.
  5. It’s open source! That’s right – Mastodon is open source. This means that anyone can stand up a server and start a community and many people can contribute to it’s development and maintenance.
  6. Fewer trolls and hate speech. Moderators are pretty diligent about trolls and hate speech. Most servers have rules against it. If the server you’re on allows bad behavior, migrate to another server. Most servers will refuse to carry traffic from individuals or entire servers, also known as blocking and defederating, that spout hate speech or harass other people on the server. The reason for this is that there is no profit motive. Twitter may be loathe to ban someone for hate speech because they have a lot of followers, making them attractive to advertisers. A Mastodon moderator has no such problem. The one I’m on even has a rule in the Code of Conduct that says “Don’t be a dick”. Can’t argue with that.
  7. People are trying to build it up not tear it down. Sorry Elon, but you’re trashing Twitter. You clearly have a “burn it down to make it better” approach to business. Mastodon is community led. The only goal is to have a good time.

What’s the big negative? The Mastodon server I’m on, – a server dedicated to music, is so engaging that I’m already spending too much time on it. I used to publish on Twitter, but never spend much time reading posts. It was fire and forget. Mastodon has the potential to become a giant time suck. That’s really not a bad thing.

Mastodon delivers community, helps discover new people and content, and provides a more healthy environment than Twitter. Twitter is none of the above and I have doubts about it as a going concern. You can’t lose more than half (probably a lot more than half) of your engineers and keep the system running as is, let alone continue to evolve it. It’s probably done like dinner. One thing I’ve learned in nearly 40 years in IT is not to stay in the dumpster when it’s on fire. I can smell Twitter burning from across the country.

If you want to follow me on Mastodon, you can find me at from most Mastodon servers. Or join It’s a great community.