Adventures in Open Source: A conversation about the journey and lessons learned

Open source did not win the security stack because someone proved it was a better way to write software. It won project by project, each one starting from a different place and arriving at the same handful of unglamorous decisions about licensing, governance, and money. None of the three people in this conversation set out to start a company. One needed a tool he could not afford. One was handed a vision and the resources to ship it. One inherited a government grant with a deadline. What they share is not an origin story but a set of early choices that compounded for more than a decade. Christopher Luft of LimaCharlie sat down with Zach Wasserman, CTO of Fleet and co-creator of osquery, Lennart Koopmann, founder of Graylog, and Peter Manev, CSO of Stamus Networks and a member of the executive team at the foundation that stewards Suricata. What emerges is not a how-to. It is an argument about which decisions you can revisit later and which ones you spend years undoing.

For an MSSP or MDR, this is not founder folklore. osquery, Graylog, and Suricata sit inside a large share of managed detection stacks, and the choices these maintainers made about licensing, governance, and funding are what determine whether the tools you build client delivery on stay alive, stay maintained, and stay yours to depend on.

Different origins, the same discipline

The three projects did not begin the same way, and the panel is careful about that. Wasserman credits osquery to Mike Arpaia, who came to Facebook in 2014 wanting to give defenders something usable on macOS and Linux, platforms endpoint security largely ignored then, and accessible to analysts who did not want to write Python scripts. Facebook was shipping projects like React at the time, so open sourcing was, in his words, not a hard sell, and osquery was public within about six months. Koopmann started Graylog in 2009 as a 21-year-old junior developer who needed log management, could not afford the commercial options everyone has heard of, and figured it could not take more than two weeks. He told the panel they are still not done, with more than 130 people now working on it. Manev describes Suricata as open source by birth, a DHS-funded effort whose first code was pushed on December 31, 2008, to hit a deadline, and the only project from that funding round that survived, which he attributes directly to its being open.

The motives differ, but the discipline converges. Publish the code, and let real users tell you whether it is worth continuing. Wasserman puts the cautionary half bluntly: it is absolutely not the case that if you build it they will come, unless it solves a problem people are hungry for. The hunger does double duty, because the more desperately someone needs the tool, the more deployment pain they will tolerate while the project is still rough. But hunger only buys time. Koopmann's first traction came from unglamorous work: building a website, choosing a license deliberately instead of grabbing a familiar one, and carrying the project around Hamburg's user groups until the Ruby community adopted it. Both he and Wasserman insist open source is no excuse for bad documentation or a painful install, and Manev adds that docs have to serve newcomers, not just the power users who can plot through anything, because the people who most need help are the least able to help themselves.

Two early choices you cannot easily walk back

If the session has a thesis, it is that a few decisions made at the very start govern everything that follows, and licensing is the one all three keep returning to. Manev calls it essential and warns it is not something you want to touch once a project is widely adopted. Koopmann lived the proof: when Graylog launched a managed cloud offering, he moved the project from GPLv3 to the SSPL, an "AGPL on steroids," specifically so a large cloud host could not resell the software without paying anything back. Smaller companies caught in that change were offered a token license rather than cut off, but the underlying lesson is that he changed a license under pressure, exactly the situation he now tells people to plan around. His closing advice names this as the part he got wrong, and the part that was painful to fix.

The second irreversible choice is governance, and the panel frames it as a genuine trade, not a best practice. Company-directed projects like Fleet and Graylog move faster because decisions do not need consensus and the team owns the end-to-end experience. Foundation-and-committee projects like osquery, now under the Linux Foundation, and Suricata under its foundation, trade that speed for resilience: losing one contributor or one sponsoring organization does not end the project, and the neutrality lets many vendors build on it. Wasserman points out that most major security vendors now integrate osquery, which the foundation model helped enable. For a provider deciding what to standardize on, that distinction is a direct read on risk. A company-directed project gives you a tighter experience tied to one organization's health; a foundation project gives you something more likely to outlive any single backer.

What actually keeps the lights on

The funding discussion is refreshingly unromantic. Consulting is where Wasserman and Manev both started, and Koopmann notes it suits a one-person project because it comes without the SLAs and 2 a.m. obligations of formal support. Support contracts come next and scale worse, because they consume an individual's time. Donations can sustain very popular projects, and the panel openly hopes more companies will fund the open source they already depend on for free. The model that genuinely scales is recurring infrastructure. Koopmann holds up MongoDB's arc from consulting to support to open core to cloud as the path to study, because customers running infrastructure software will always pay to stop caring about maintenance and scaling. Wasserman describes Fleet's buyer-based open core model, some code fully open under MIT and some commercial, chosen precisely because it lets an engineering organization scale instead of depending on headcount. Manev surfaces the maintainer's side of the same problem: accept a feature with nobody dedicated to supporting it and you put the whole project at risk, which is why he and Koopmann both pushed contributors to talk through work before building it. Koopmann's answer to contribution chaos was a public roadmap, and his answer to good contributors was a job offer.

On the oldest objection, that open code is less secure, the group is unanimous and unsentimental. Wasserman rejects security through obscurity outright and argues that scrutiny forces better discipline and honest self-assessment. Manev observes that open projects often face more pressure to fix vulnerabilities fast and in public, and frequently outperform commercial counterparts on responsiveness, while noting that being open neither causes nor prevents CVEs. Koopmann adds the practical upside that matters for a stack built on these tools: vendors increasingly give genuine open source projects free supply-chain and dependency scanning, GitHub and GitLab now ship much of that tool chain, and the security.md convention gives reporters a clear channel. The responsibility that remains, he says, is to actively retire abandoned code rather than leave outdated software lingering. That is the quiet test for anyone choosing what to depend on. Not whether a project is open, but whether the people behind it still treat its maintenance as their job.