Abstract
Adiscon runs two first-class lines of work: open source and closed source. We apply clear policies per project, keep boundaries explicit, and share engineering concepts and practices where that makes sense. This post explains the pattern: how we develop in both worlds, how ideas flow in both directions, and why we consider that co-evolution a strength. We publish this now because our applied AI work spans multiple projects and contexts, and it follows the same pattern. Going forward, we will use adiscon.com as the cross-project home for that work, with clear links to upstream and product artifacts.
Scope
This is not a product announcement. It is a short engineering note about how we work, how we separate responsibilities, and how we avoid common misunderstandings when one team builds both open source and commercial software.
Two first-class lines, clear boundaries
We treat open source and closed source as first-class citizens. Each has its own constraints and responsibilities.
For rsyslog on Linux, we work upstream. We do not like open-core and dual-licensing models in that context. In infrastructure software, those models often create two trajectories: the best work accumulates behind a paywall while the open source edition turns into a compatibility layer. We chose a different path. If a capability belongs in rsyslog, we implement it in rsyslog.
At the same time, we also ship closed source products where closed source is appropriate. We keep that explicit. We fund engineering through the typical open source business model: support, consulting, and custom development, plus clearly labeled commercial offerings.
A short historical note
Adiscon started as a commercial software company. We have shipped closed source software since 1997, with engineering roots in the precursor company going back to 1988. In 2004 we made a deliberate decision to do open source as well, and rsyslog became our main upstream project in that space. That history is context. The main point is how we run the two lines today and how we manage co-evolution between them.
Concept transfer, not code copying
When people hear “open source and commercial products in one company,” they sometimes assume direct code transfer or a one-way pipeline. That is not how we work.
We transfer concepts, best practices, and operational lessons. We re-implement under the constraints of the target system. Different environments demand different tradeoffs, different interfaces, and often different code. This is the only sustainable way to build serious systems across different products and communities.
Co-evolution in practice
We have a long history of bidirectional learning.
From commercial work into rsyslog, we brought early concepts that were unusual in the syslogd world at the time:
- modular design as a way to control complexity,
- thread awareness as a requirement for predictable behavior at scale,
- and the idea of a broader network event abstraction rather than thinking in terms of “syslog only.”
From rsyslog back into commercial products, we carried over concepts as well. A concrete example is the idea of disk queues and extended buffering. The implementations differ, but the underlying approach to reliability under pressure influenced how we built and evolved commercial systems.
The important point is not which side “invented” something. The point is that each environment exposes different failure modes and forces different discipline. We treat that as an advantage.
Picking the right pilot context
We choose the proof-of-concept context that best fits the task.
Sometimes open source provides the best environment because it offers broad exposure and fast feedback across a wide ecosystem. Sometimes commercial products provide the best environment because they bring clear operational requirements and support obligations. Sometimes a civic project provides the best environment because it forces clarity, provenance, and human review under very tight constraints.
We use the simplest context that lets us validate the method without creating unnecessary risk. Then we apply what works more broadly.
How we will publish going forward
We will use adiscon.com for long-lived technical writing that spans products and contexts. These posts are not release notes and not marketing copy. They document method.
Each deep dive follows a consistent structure so readers can find what they need and cite it:
- scope and definitions
- constraints and assumptions
- design decisions and tradeoffs
- current status (planned, pilot, production)
- evidence and limits (what we observed, what we cannot attribute yet)
- artifacts and references (code, docs, tools, benchmarks where we can publish them)
This format also supports follow-up work. When we publish a new subproject or update an existing one, we can link back to the relevant deep dives and keep a clear paper trail.
What comes next
This post describes the pattern and the policies. Next, we will publish a concrete breakdown of our current AI efforts: the subprojects, what each produces, where it runs (open source, commercial products, civic pilots), and how we plan to evaluate results without leaning on hype.