As the title says, AxoSyslog is now a real fork of syslog-ng™ (syslog-ng is a trademark of One Identity). As the founder of the original syslog-ng project, I am emotionally attached to the project and the name, still, I have decided to part ways with that and open a new chapter. This blog post shows my intentions and our plans going forward.

AxoSyslog started as a cloud native distribution for syslog-ng: we packaged syslog-ng in a container, added helm charts and improved it to behave better when used in a cloud native environment. We also introduced several features and improvements, which we added to the original syslog-ng repository. The new features improved the monitoring and operational experience to help AxoSyslog integrate better to a modern telemetry pipeline. We were adding these features because we use AxoSyslog in our stack at Axoflow, as part of the product’s data curation pipeline.

As time passed, my colleagues and I found ourselves being the primary contributors for syslog-ng, contributing over 90% of the patches, and creating features such as support for Grafana Loki and the OpenTelemetry protocols and schemas. These features were driven by our agenda of creating our product, but since we added these features to the open-source syslog-ng repository, the software we produced became available to both traditional syslog-ng users as well as AxoSyslog users – and also to projects building on these projects (like the Logging Operator which can use AxoSyslog as a log aggregator, or Splunk Connect for Syslog (SC4S)).

During this year and a half, we were the de-facto maintainers of the syslog-ng project: not only did we create most of the features, but we were also reviewing the incoming contributions and managing all the releases since syslog-ng 4.1. We also produced up to date documentation, because the “official” documentation set was not updated regularly.

Is forking really needed?

I did not take the question of forking lightly. Forking can be both good or bad news for the community. 

• The bad: forking can mean that the user and developer community is split and with that the goodwill and mindshare related to a project potentially decreases.
• The good: if a project becomes unsustainable, the fork might be the only opportunity to resolve those conflicts. It is great that free and open source software provides this freedom to better serve the larger community in general.

I had high hopes for the collaboration on the syslog-ng project last year. I thought that finally there would be multiple independent, commercial organizations working on the codebase and with that it could become a truly open source project – an independent entity of its own, collaboration done in the open, and positions and decisive power determined by merit.

That is not what happened.

What did happen was that the confusion around the project only increased. One example is the fact that we now have 3 documentation sets that each describes syslog-ng™ (the “official”, largely unmaintained, our own and up-to-date under the AxoSyslog name, and another one, just recently published). For the one published under the AxoSyslog name, we have converted the documentation from a proprietary format to markdown, updated it to the latest version, and published it on our website, under our brand name, because we were legally restricted from using the syslog-ng name.

But there are other issues and asymmetries in the syslog-ng project, which led me to seriously think about forking. The final straw has been a friendly warning to include “™” marks for any mentions of syslog-ng™.

However, instead of concentrating on what we can’t do, there are very good reasons for the fork:

• Avoid all confusion and use consistent naming for AxoSyslog: package, container, helm chart, documentation, blog, etc.
• Focus communication on new things: OpenTelemetry, the filterx language we are currently working on, performance improvements, and other reasons why it makes sense to upgrade to AxoSyslog.
• Make the project more welcoming to new users, so they understand why it has a loyal user base.

AxoSyslog next steps

The fork does not change things much: we will continue to be good stewards of the AxoSyslog code, and keep on doing everything we have been doing up to this point: 

• develop new functionality, 
• publish releases, and 
• update the documentation as a part of building Axoflow.

The name is different, thus the GitHub repository changes as well: the new home is at https://github.com/axoflow/axosyslog, where you can find packages, containers, helm charts, and so on. You can find the source of the AxoSyslog documentation at https://github.com/axoflow/axosyslog-core-docs/ (this hasn’t changed).

Why “Axo” in the name?

I understand that using a non-Axo brand would be better for an Open Source project, but we’ve already started using AxoSyslog for our purposes (and our plans never included creating a full fork). Building another brand/website/etc is a hassle and would seem like we are restarting from scratch. 

I am not against using a different name in principle though. Just ping me (email, discord, reddit) if you feel that way, so we can discuss it and find ways to make it happen.

Important links

• Discord for questions and community support
  
• AxoSyslog source code
  
• Packages:  We’re providing DEB and RPM packages, starting with our first independent release (AxoSyslog 4.8)
  
• Containers
  
• Helm charts
  
• Documentation

What to do now?

Give AxoSyslog a try. Give us a star on GitHub. File your issues there. Follow the Axoflow blog where we publish posts about new releases and features.

Sign up to our Discord server and tell us what you think!