{"id":34506,"date":"2026-08-13T15:04:00","date_gmt":"2026-08-13T13:04:00","guid":{"rendered":"https:\/\/orcharhino.com\/ressourcen\/blog\/10-years-of-orcharhino-a-look-back-from-engineering-team\/"},"modified":"2026-08-14T11:42:36","modified_gmt":"2026-08-14T09:42:36","slug":"10-years-of-orcharhino-a-look-back-from-engineering-team","status":"publish","type":"post","link":"https:\/\/orcharhino.com\/en\/resources\/blog\/10-years-of-orcharhino-a-look-back-from-engineering-team\/","title":{"rendered":"10 Years of orcharhino: A look back from the Engineering team"},"content":{"rendered":"\n
\"\"<\/figure>\n\n

When I started at ATIX AG almost ten years ago, orcharhino was still a long way from the product it is today. Back then, orcharhino essentially consisted of two projects: an \u201corcharhino\u201d for managing RPM-based systems and \u201cTiki\u201d for Debian. At that time, Tiki was still based on Spacewalk. <\/p>\n\n

<\/div>\n\n

A lot of it had to be built by manually. Although there was detailed documentation, many manual steps were still a natural part of our daily routine. Today, that\u2019s hard to imagine. Back then, that was simply the way we worked. <\/p>\n\n

<\/div>\n\n

Two other colleagues joined me at the start. Together with the two existing developers and the consultants, we set out to turn what was then just a project into a reliable product, step by step. In the beginning, a lot of it was still very hands-on: We developed features, put together releases, wrote documentation, and often took it upon ourselves to ensure that the new features made their way to the users. <\/p>\n\n

<\/div>\n\n

From Manual Processes to Automation<\/h2>\n\n

Over time, the manual steps involved in creating the orcharhino packages evolved into a fully automated packaging process. \u201csnapshot_management\u201d became the first plugin to be included in orcharhino. At the same time, we were already working on the next extension to improve integration with SUSE Linux Enterprise. <\/p>\n\n

<\/div>\n\n

Ein gro\u00dfes Thema war damals auch die Installation von Foreman und Katello. Beide Open-Source-Projekte bilden wichtige technische Grundlagen von orcharhino, waren zu dieser Zeit aber h\u00e4ufig nicht einfach zu installieren und zu betreiben. Mit Ansible und einem leichtgewichtigen webbasierten Installer wollten wir unseren Consultants das Leben leichter machen und gleichzeitig f\u00fcr reproduzierbarere Installationen sorgen. <\/p>\n\n

<\/div>\n\n

It was precisely in situations like these that it became increasingly clear to me what product work really entails. It\u2019s not enough to simply put together individual open-source components. They must be integrated, tested, documented, and reliably maintained over the long term. On top of that, there are custom extensions, scheduled releases, and support that takes responsibility when problems arise. <\/p>\n\n

<\/div>\n\n

The Breakthrough in Debian support<\/h2>\n\n
<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n

Debian support remained one of the most challenging areas at first. \u201corcharhino Tiki\u201d was a separate solution, while the core orcharhino lacked support for Debian packages. But it was precisely this gap that motivated us to continually reevaluate existing approaches. <\/p>\n\n

<\/div>\n\n

The breakthrough finally came with orcharhino 3.0 and its Debian package support, as well as version 4.0 with Debian errata support. This allowed us to manage RPM- and Debian-based systems via a common platform for the first time. <\/p>\n\n

<\/div>\n\n

For us, this was more than just another feature. It was an important step toward what orcharhino is today: a vendor-neutral system for the lifecycle management of various enterprise Linux distributions. <\/p>\n\n

<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n

From individual distributions to a broad platform<\/h2>\n\n

This trend continued in the years that followed. We integrated Salt support and later took over maintenance of the Puppet plugin as well. We added new integrations and expanded orcharhino to include enterprise features, such as the use of Proxmox as a compute resource. <\/p>\n\n

<\/div>\n\n

As our customer base grew, new requirements continued to emerge. What began as support for RPM-based systems and Debian gradually evolved into a platform supporting SUSE, Red Hat, Debian, Ubuntu, AlmaLinux, Oracle Linux, and Rocky Linux. For some operating systems, we now also support ARM64 and PPC64. <\/p>\n\n

<\/div>\n\n

It is precisely this versatility that many of our customers value. They can manage different distributions and architectures through a single system without being completely tied to a single operating system vendor for lifecycle management. <\/p>\n\n

<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n

The team has also grown along with orcharhino<\/h2>\n\n

Our team has also undergone significant changes. Starting with just three employees and a few consultants who were also working on orcharhino, the engineering team is now the largest team within ATIX. <\/p>\n\n

<\/div>\n\n

In the early years, the roles were much less distinct. We wrote code, built packages, maintained the documentation, drafted release notes, and sometimes even wrote the tweets ourselves. Today, there are specialized teams for marketing, communications, and public relations. <\/p>\n\n

<\/div>\n\n

To me, that is a wonderful sign of just how much orcharhino and ATIX have grown. Many things that used to be handled on the side are now part of professional and clearly defined processes. <\/p>\n\n

<\/div>\n\n

Nevertheless, our work on the engineering team has remained very diverse to this day. In keeping with the DevOps philosophy, we don\u2019t just handle traditional development. We also work on the documentation that many customers value, operate various test infrastructures, some of which are fully automated and are involved in running the orcharhino release system. <\/p>\n\n

<\/div>\n\n

Of course, this delivery system also runs on orcharhino.<\/p>\n\n

<\/div>\n\n

Without automation using Ansible, OpenTofu, and orcharhino, we would hardly be able to handle this wide range of tasks on our own. For us, automation has never been just a technical goal. It has always been a prerequisite for supporting more platforms, delivering more frequently and reliably, and continuing to grow as a team. <\/p>\n\n

<\/div>\n\n
\"\"<\/figure>\n\n
<\/div>\n\n

Ten years of open source and community<\/h2>\n\n

Over the years, we have been, and continue to be part of the Foreman community. Many discussions on the forum and in chat, collaborative work on pull requests on GitHub, and numerous encounters at conferences have shaped our work. <\/p>\n\n

<\/div>\n\n

Collaboration with the community was never just an abstract aspect of the open-source world. It often revolved around very specific questions: Why does a component behave this way? How can a bug be fixed properly? Would a change be useful for other users as well? And how can a solution be designed so that it remains maintainable in the long term? <\/p>\n\n

<\/div>\n\n

Without the community, orcharhino wouldn’t be the product it is today. I’d like to express my sincere thanks for every code contribution, every constructive and sometimes critical review, every discussion, and every bit of support with difficult problems. <\/p>\n\n

<\/div>\n\n

At the same time, we have invested a great deal of effort over the years to turn these open-source foundations into a comprehensive enterprise product. This includes not only our own development work, but also release engineering, packaging, quality assurance, documentation, and professional support. <\/p>\n\n

<\/div>\n\n

It is precisely this behind-the-scenes work that transforms technical functionality into a product customers can rely on in their day-to-day operations.<\/p>\n\n

<\/div>\n\n

From a co-funded project to a core product<\/h2>\n\n

Initially, the development of orcharhino was co-financed by ATIX’s consulting business. Today, orcharhino is the company’s core product. <\/p>\n\n

<\/div>\n\n

Over the past ten years, we\u2019ve written this story together as a team: with the many long-time developers in Engineering, with our colleagues in Support who give their all every day to assist our customers, and with Marketing, Sales, and Consulting, who often identify new requirements very early on and bring them to our attention.<\/p>\n\n

<\/div>\n\n

And, of course, to Mark and Thomas, whose many challenges during development prompted us to reevaluate our solutions and make them even better.<\/p>\n\n

<\/div>\n\n

When I look back on the past few years today, I don’t just think about individual releases or features. Above all, I think about the many technical decisions, big and small, the long debugging sessions, the discussions about architecture, the pull requests that took more rounds than expected, and the moment when a solution finally worked reliably. <\/p>\n\n

<\/div>\n\n

It is precisely through these many steps that orcharhino has become what it is today.<\/p>\n\n

<\/div>\n\n

What happens next?<\/h2>\n\n

With OpenTofu’s support for compute resources and the addition of Ansible Director, we’ve broken new ground. Both projects have a lot of potential, and it will be exciting to see what impact they will have in the future. <\/p>\n\n

<\/div>\n\n

Digital sovereignty, containerization, and artificial intelligence will also transform orcharhino in the future. For us as developers, this means evaluating new technologies, refining existing concepts, and never losing sight of what customers truly need in a production environment. <\/p>\n\n

<\/div>\n\n

We’ll likely be sharing more about this soon at a community event, at the next orcharhino Summit, or by the time of orcharhino’s 20th anniversary at the latest.<\/p>\n\n

<\/div>\n\n

Happy Birthday, orcharhino!<\/p>\n\n

<\/div>\n\n
\n