Software Engineering and Stuff

When people think about open source, they often picture lines of code, clever algorithms, or maybe a GitHub repository full of issues and pull requests. What can be harder to see is the human side. The people who quietly keep things moving, who make sure contributions land smoothly and help the community grow in a healthy way. That’s the work of a maintainer.

Maintainers are more than just code reviewers. They are the stewards of the SIG’s (Special Interest Group) health, direction, and community. They balance technical oversight with mentorship, governance with collaboration, and long-term vision with the day-to-day realities of issues and pull requests.

Let’s start with an opinion: Open Source software (OSS) is awesome, and better than proprietary.

However, being able to call your software truly Open Source is not necessarily that easy. The Open Source Initiative provides a pretty strict definition of what can be called Open Source.

And several OSS projects have kind of lost their “Open Source” stamp these past few years by switching to less permissive licences.

However, even within the wide range of open software, there is open and open. And while being Open-Source does not imply open contributions, many projects do welcome them. That’s the ones I want to talk in this post.

For a very long time, it appeared obvious to outside observers of the time flow that Skynet would never win the war, and never annihilate humanity.

Despite the machine’s violent attempts to destroy every leader of the resistance, humans always prevailed. Millions of attempts were made, and none of them succeeded. It became obvious the machines couldn’t win through violence.

Even though Skynet was pretty long to come to the conclusion that it couldn’t win (millions of attempts is a pretty high number of failures), it did learn something from each failure, and started devising a new plan.

If you maintain a Go library, you may want, or your users may want you to use semantic versioning when you make changes.

When you try to achieve that, it sometimes feels like every change will be a breaking one, and warrant a major release. You most likely don’t want to do major releases every other day though.

You will find here some coding patterns that may help you architect Go libraries so you can abide to Semantic Versioning, and avoid some breaking changes.

One of the books that impacted the most my career is probably The Mikado Method. I read it almost 10 years ago, and I don’t practice it explicitly. But I think of the method almost every day, and it has been impacting how I work ever since.

And yet, it has remained something quite obscure. Whenever folks suggest must-read computer science books, it’s never there. So let’s try to explain it a bit more, and how it can be used every day in the life of a programmer.

Modern telemetry libraries allow easily configuring auto instrumentation, to automatically gather observability data about frameworks and libraries.

There are two main approaches to architecting those auto-instrumentation libraries. As middlewares/wrappers, or as monkey-patches. I believe middlewares are much better, here’s why.

OpenTelemetry is making observability much easier, especially by providing the first widely accepted vendor agnostic telemetry libraries. The first signal the project implemented is tracing, which is now GA in most languages.

Ever since we need to operate hardware and software in production, we have needed to know how those behave. For example, when I brew craft beer, I use an iSpindle to monitor the temperature and the gravity of my wort.

In this article, I would like to suggest the use of a very common pattern in Go, Functional Options, but adapted to the Ruby language.

OpenTelemetry is a quite new tool meant to provide a standard interface to for handling metrics and traces.

It provides libraries in all main languages, and its collector component allows receiving data from any app in any language, and transmitting them to any observability platform.