A maintainer announces funding, and the open source world exhales. The pattern has become familiar: a small but useful project hits the wall, a quiet fundraising push, a “we are saved” post, the calendar moves on. SparkleShare’s August 2026 funding news is a version of that story. Hylke Bons, the freelance designer and coder behind the Git-based file-sync application, has found support to finish a Rust port, bring the software in line with current security and privacy practice, design a fresh user interface, and put a Linux release back on Flathub (a Flatpak, or self-contained Linux app package, distribution site that is the default way most desktop Linux users install graphical software). A Flatpak of SparkleShare was previously pulled from Flathub because Bons could not keep it maintained while holding a day job.
What makes this story different is not the rescue. It is the source. Bons got the funding from NLnet Foundation, an organization that has been quietly writing checks for open internet projects since 1997. The implication, which the original coverage spells out, is the part that has stuck with me: at the time OpenSSL was hemorrhaging maintainer hours and the world was panicking about Heartbleed, NLnet was almost certainly there for the asking. They were not asked. OpenSSL was not funded through them. Twelve years later, NLnet is still writing the same kinds of checks. The plumbing on the funder side never broke. What broke, repeatedly, is the discovery layer.
How the open source funding pile is actually organized
The open source funding landscape, in the way I now think about it after reading the FOSS Force coverage, breaks into four rough layers, and they are not equally visible to a maintainer in distress.
- Pre-2014 funding organizations. These are the foundations and grants that have been quietly writing checks for decades. NLnet, the foundation that funded SparkleShare, is the canonical example. The organization says on its homepage that it has been “supporting the open internet since 1997.” Most of these foundations have small staff, small budgets, and a stated mission that is not “rescue the latest project that the internet cannot live without.” They fund work. They are not in the business of marketing themselves to maintainers who do not know they exist.
- The funding community that grew up around specific open source projects. SparkleShare is a Git-based file-sync application, and the project has been around since 2010. The kind of project that ends up on a pre-2014 funder’s radar is exactly the kind of project the funder has been funding for 28 years: a small, well-known, dependency-of-other-things piece of software that one person has been quietly maintaining.
- Post-Heartbleed funding infrastructure. The 2014 OpenSSL vulnerability (a memory disclosure bug in OpenSSL, the TLS library that secures most HTTPS traffic, that let attackers read server memory and steal private keys) was the wake-up call that produced the Linux Foundation’s Core Infrastructure Initiative, the OpenSSF (Open Source Security Foundation), and a handful of successor programs. These were designed specifically to put money in front of maintainers of “boring but critical” infrastructure before the next disaster. They have done real work. They are also the most visible layer, which is part of why newer maintainers sometimes assume they are the only layer.
- Project-specific grants and sponsorships. GitHub-style sponsorship platforms, Open Collective-style fiscal hosts, and grant programs that companies and foundations run for particular kinds of work. These are well-indexed, easy to find, and the easiest layer for a maintainer to discover.
SparkleShare is interesting because the funding that rescued it came from layer one. NLnet was not a Heartbleed-response organization. They were already a Heartbleed-response organization in 2014; they just had a different name and a different front door.
The lesson that is not about NLnet
The interesting part of the story, for me, is not that NLnet exists. It is that the maintainer found them. Bons had a specific reason to be looking. He needed money for a Rust port and a security refresh, which is exactly the kind of work NLnet has been funding for the last 28 years. The match was almost too clean.
Most maintainers in distress are not looking for a specific kind of funding. They are looking for “any funding.” That is a search problem with a very different shape. The post-Heartbleed layer is well-indexed because it was built to be found. The pre-2014 layer is well-indexed only if you already know what you are looking for. A maintainer who finds out about NLnet in 2026 is more likely to be a long-time reader of open source news than a developer in burnout mode who has just dropped a Flatpak from Flathub.
The Heartbleed story is the same shape. The maintainers at OpenSSL were underfunded for years. After the disclosure, the conversation was “we should have been funding this.” The same conversation could have happened a decade earlier. The funding was there, if the maintainers had known to ask, and if the foundations had known to advertise themselves as the answer. Neither side had a strong incentive to build the bridge, because the disaster that justified the bridge had not happened yet.
What a maintainer who is reading this should do
If you are a maintainer of a small, unsexy, working piece of infrastructure, and you are wondering whether you should apply to NLnet or one of the other pre-2014 foundations, the answer is yes. The application process is not fast, and it is not always a fit, but the foundations exist specifically to fund what you are doing. The pre-2014 layer is harder to discover, but it is also less competitive than the post-Heartbleed layer, because most maintainers in distress are not looking there.
The practical first step is to identify whether your work is “open internet” work, in the way the pre-2014 funders use that term. “Open internet” funding covers the protocols, libraries, and standards that the open web runs on. If your project is a consumer-facing application that happens to be open source, the pre-2014 layer is less of a fit. If your project is a library, a protocol, an editor, a content tool, or any kind of infrastructure that other open source projects depend on, the pre-2014 layer is the most likely source of meaningful funding.
The next step is to apply to two or three of them at once, with a clear description of the work, the budget, and the timeline. The pre-2014 layer is not allergic to multi-year grants, and it is not allergic to paying for design work or UI refresh, which is the part of SparkleShare that surprised me. The grant that funded SparkleShare included a UI redesign informed by community feedback. That is not the work that post-Heartbleed funders prioritize, and it is exactly the work NLnet funded.
What I would tell the version of me that was panicking about an unfunded project
If I could send a message back to the version of me who was once the maintainer of a small, useful, totally unfunded piece of code, three things:
- The funding was probably there. The pre-2014 layer is real. It is not well advertised, but it is not exclusive. The application process is not fast, but it is not gated on a personal connection. Apply.
- Specify the kind of work, not the kind of project. The post-Heartbleed layer funds critical infrastructure. The pre-2014 layer funds work, full stop. If your work is “port this to a memory-safe language and refresh the security model,” that is a fundable project even if the application is a desktop file-sync tool.
- The discovery problem is not your fault. A maintainer who does not know to look for the pre-2014 layer is not underinformed. The pre-2014 layer does not advertise. The post-Heartbleed layer does, which is why you have heard of it. If you have not heard of NLnet, that is a discovery problem, not a knowledge problem.
Trade-offs
The SparkleShare story is not a clean win. The Rust port, the security refresh, and the UI redesign are all real work, and the timeline will slip in the way that all real timelines slip. The maintainer who is now funded to do the work is the same maintainer who was burnout-removed from Flathub a year ago. The funding does not reset the burnout clock. It extends it. If the timeline slips by a year and Bons is back in burnout mode at the end of the grant, the project is in a worse position than it was before the funding arrived, because the maintainer has now committed publicly to a roadmap and cannot quietly walk away from it.
A second cost is that single-maintainer funding is fragile. A grant that funds one person for one piece of work is a grant that ends when that piece of work ends. The post-Heartbleed funding model tries to address this by funding multiple maintainers and by funding organizations, not individuals. NLnet’s model is closer to the individual-maintainer end of the spectrum. That is a real choice, and it has trade-offs: individual funding is faster, less bureaucratic, and better at supporting the kind of focused work that Bons is doing. It is also more fragile.
A third cost is that the discovery problem this article describes is not solved by writing about it. There are dozens of pre-2014 foundations, and each one has its own application process, its own timeline, and its own criteria. A maintainer who reads this and decides to apply is still facing the friction of writing a grant application, waiting months for a response, and possibly being told no. The pre-2014 layer is not a vending machine. It is a stack of grant applications and a small number of reviewers. The volume of applications is going to go up, and the response time is going to go up with it, which is the opposite of what maintainers in distress need.
The migration cost for a maintainer adopting this strategy is real but bounded. A reasonable first grant application takes about a week to write, including the budget and the timeline. The first response usually comes in 4-8 weeks. The probability of being funded on the first try, from my read of the public record, is somewhere between a third and a half, depending on the foundation. None of these numbers are reasons not to apply. They are reasons to apply early, before burnout, when the maintainer still has the energy to write a coherent application.
If you are a maintainer who has been thinking about applying for funding and has been putting it off, the only condition under which you should keep putting it off is that you are about to walk away from the project anyway. If you are staying, apply. The funding was probably there. The discovery problem is not your fault. The application is the next step.
Bottom line
SparkleShare’s funding story is not a story about NLnet. It is a story about the pre-2014 funding layer being real, well-funded, and undersubscribed by exactly the maintainers who most need it. The discovery problem on the maintainer side, and the advertising problem on the funder side, are not new. They are the same problems that produced Heartbleed. The fix is not more post-disaster funding programs. The fix is more maintainers applying to the programs that already exist.