Keep SysWarden independent.
Fund the work behind it.

The work continues after a release.

A release is a visible milestone. Maintenance fills the space between those milestones. Dependencies move, distributions change, kernels evolve and users bring configurations that a clean installation never encounters. Someone has to reproduce those conditions, understand the failure and check that the correction holds.

Consider a package upgrade on a hardened Linux host. Testing the new installation is one step. Testing an older installation that has passed through several versions is another. Then come interrupted upgrades, service restarts, reboots, removal and reinstallation. A useful correction has to respect the operator's configuration throughout that journey.

That takes machines, repeatable test environments and patient engineering. It also takes time to explain what happened and write recovery instructions that people can actually follow. A clear paragraph in the documentation can spare an administrator a long evening. I want to keep making room for that work.

Make room for someone else to look closely.

I want SysWarden to benefit from independent security audits and penetration tests. Maintaining a project gives you deep knowledge of its design. An external reviewer brings different assumptions, different habits and questions you may have stopped asking.

A code audit can examine trust boundaries, privilege handling, input validation and failure paths. A pentest can challenge the deployed system and the assumptions around its configuration and operation. Both need a defined scope, a suitable environment and time to investigate the findings.

The work then continues: fix the issues, review the changes, repeat the relevant tests and document the outcome. Funding that follow-up is part of funding the review. Otherwise, a report risks becoming another file waiting for attention.

Automated checks remain useful daily tools. Independent review adds another perspective. My aim is to make that outside scrutiny easier to commission and sustain as resources allow, with clear information about what was assessed and what remains to be done.

Release assurance also takes sustained effort. SysWarden uses IVV, meaning Integration, Verification and Validation, for intermediate releases. Upgrade generations require full IVVQ, adding Qualification. The release assurance documentation explains that distinction and the evidence behind it.

Independence needs a sustainable footing.

I want to keep making technical decisions according to what helps the project and its users: addressing a difficult bug, improving a recovery path, revisiting an assumption or delaying a release when the evidence calls for it.

Community funding can help protect the time needed for those decisions. Several people making manageable contributions can give an independent project more breathing room. The useful amount is the amount that fits your circumstances.

The recurring costs are ordinary ones: compute, storage, backups, domains and the infrastructure used to build and test. Specialist reviews add professional time. Maintenance adds the hours spent turning a reported problem into a correction that is understandable and verifiable.

These costs vary with the testing workload and the scope of external reviews. Funding helps pay for the conditions in which careful work can happen. The source, documentation and release record remain places where you can follow that work.

Coming next: support for business deployments.

I am also preparing a support offering for companies that want to deploy SysWarden in their own infrastructure. The aim is practical help with deployment planning, integration, configuration review, upgrades and operational questions.

For a business, having open source available and having access to dedicated assistance serve different needs. A team may be comfortable running Linux while still wanting a maintainer's help to assess a deployment path or work through a specific integration.

The scope, availability and terms of that offering still need to be defined before it opens. I will publish those details through the official SysWarden channels. For now, this is a direction I am working towards. Donations support the project; they do not purchase a support contract or a response-time commitment.

If your organisation is interested, you are welcome to contact me to discuss the kind of help you would need. Those conversations can help shape an offering grounded in real deployment work.

Your contribution can take another form.

A reproducible bug report, a careful review, a documentation improvement or useful feedback from a test environment can all move SysWarden forward. Sharing the project with someone who needs it helps too.

If money is tight, please keep it for your own priorities. You are welcome in the community either way. The documentation, repository and community space are good places to start.

My ambition is straightforward: keep building useful Linux security software, give it the scrutiny it deserves and make it easier for people to operate with confidence. If you would like to help sustain that work, thank you. It means a great deal.