At Dokapi, we’ve long relied on the robust and precise libraries developed by Philip Helger to power our Peppol infrastructure. His work has become so ubiquitous in our projects that whenever we hit a wall, one asks, ‘Check if Philip already solved it' - and odds are he often has.
In a recent interview, we had the opportunity to speak directly with the man himself and learn more about the driving force behind his prolific contributions to the Peppol ecosystem.
The origin story: building blocks for a complex standard
Philip, based in Vienna, has been contributing to Peppol-related open source development for over 15 years. As he puts it, “OpenPeppol provides the specs, but not the code.” Frustrated by the lack of shared technical infrastructure early on, he began creating reusable libraries to simplify implementation. These libraries have since evolved into a comprehensive “Lego set” of interoperable components used by many across the ecosystem.
Despite their scale and influence, the libraries remain the work of a single, focused developer. He still writes around 99% of the code himself. His disciplined and opinionated approach to coding is evident in his meticulously structured configurations, which create a consistent and high-quality codebase. Some contributors have expressed hesitance to jump in for fear of "breaking the style."
“People think they’ll mess it up, or that they’ll be judged. But honestly, I’m just grateful for any contributions,” Philip says. Even so, the technical design’s depth and modularity (sometimes spanning five layers) can be intimidating for new contributors. He encourages anyone interested to simply reach out and start a conversation.
On security, governance & scalability
As the adoption of Peppol expands, regulatory and security requirements are increasing. Philip is clear: most new security mandates are governance-related rather than technical. He participates primarily at the software architecture level, ensuring that new specifications remain technically feasible. “I always make sure we don’t specify something that’s impossible to implement,” he emphasizes.
From a scalability standpoint, his Phoss SMP and AS4 libraries remain go-to solutions for many. Over 50% of production SMPs are now powered by his software. While the PHOSS SMP is well-suited for systems with up to 10,000 participants, larger-scale implementations are not its primary focus. Nevertheless, Philip has been known to provide quick fixes on short notice, allowing the Phoss SMP to remain viable even in these more demanding scenarios.
Sustainable scaling in open source
Philip works as an independent consultant for OpenPeppol and develops his open-source tools largely in his spare time. Urgent fixes and feature requests can be prioritized through sponsorship, but most of the work is unpaid and passion-driven. Looking ahead, Philip is focused on maintaining quality, keeping the libraries evolving, and onboarding more contributors. “Just get in touch,” he says. “Let’s discuss your ideas or issues. That’s the easiest way to help.”
A note on the new SML proposal
Philip also weighed in on the proposal to decentralize Peppol’s SML infrastructure. Technically, he sees the logic. Decentralization reduces single points of failure. But from a governance perspective, he’s cautious: “Distributing SMLs could lead to jurisdictions limiting participation, which is contradictory to Peppol’s spirit of openness.”
Final thoughts
At Dokapi, we admire not only the incredible technical depth of Philip’s work, but also his continued openness and humility. His libraries are core to our daily work and have helped us scale and adapt to complex challenges over time.
We thank Philip for his tireless contributions to the open-source community and encourage others in the Peppol ecosystem to engage, contribute, and support this important work.
