Funding open-source software without compromising it<br>Funding open-source software is a challenge, especially for projects without a<br>large existing community. While various approaches exist, they all come with<br>their own drawbacks. For example, asking for donations is by far the most<br>commonly used approach but also the least effective: you can ask (or pretty much<br>beg) for donations for years and maybe you'll receive $10 per month.<br>Heartbleed is probably the most<br>well-known vulnerability that highlights the problem of important but<br>chronically under-funded open-source software projects.<br>Other alternatives tend to compromise the project in some way. For example,<br>starting a side business of sorts (e.g. one that uses the project in question)<br>means you now have to balance two jobs: the open-source project that you want<br>to work on, and the commercial offering that is supposed to pay the bills.<br>Another option is to take the open-core approach: the project is proprietary and<br>there exists an open-source fork of sorts that contains a reduced feature set,<br>in an attempt to entice users to use (and pay for) the proprietary version<br>instead. GitLab is an example of one such<br>project/company. While this too can work, almost always does it end up<br>compromising the open-source version in some way, such as when features that<br>previously existed in the open-source version are made proprietary instead<br>because some C-whatever-O determined this was in the best interest of the<br>sharehold..err I mean the community of course!<br>Then there are software grants such as those provided by<br>NLnet. These are essentially (larger) donations but with<br>additional requirements and caveats. Unfortunately, these typically come in one<br>of two forms:<br>Grants that are only open to existing large projects<br>Grants that come with highly specific requirements, such as you needing to be<br>a resident of a specific country<br>NLnet used to be an exception to this, but this too changed in recent years<br>and the requirements today unfortunately exclude a lot of projects. Sovereign<br>Tech Agency is the only grant organisation that I<br>know of that did (not sure they still do) grant money to projects that have<br>yet to establish themselves, but it came with the caveat that you had to be<br>based in Germany to be able to apply. FUTO appeared to be<br>a promising alternative, until I found out that the the organization is<br>problematic at best (and<br>that's me trying to be nice) and not something I'd want to associate myself<br>with.<br>So why am I beating the dead<br>horse that is "open-source<br>funding is difficult"? Well, because for the last year or so I've been more<br>actively trying to figure out how I can fund the long-term development of<br>Inko without compromising the project somehow.<br>Just relying on donations is something I don't see working out in the<br>long-term as it's just not reliable enough when it comes to providing a steady<br>income. One month you may be lucky and receive $500, while the next everybody<br>cancels their donations because you said you don't mind pineapple on pizza.<br>Grants is something I've looked into extensively and there just aren't any (that<br>I know of) that would accept Inko. Which brings me to the idea of running a side<br>business.<br>On paper I like the idea of running a business: no manager breathing down your<br>neck, no overpaid directors that just move numbers across spreadsheets and<br>somehow get paid 10x than the most important developer in the company, no "you<br>must use AI or you'll get fired" nonsense, and so on. Of course there are also<br>challenges such as having to do everything yourself and sales being difficult,<br>especially if you tend to under-sell your work like I do.<br>One important requirement I have though is that whatever the product is, it<br>must be open-source. Not open-source as in open-core, but truly open-source.<br>This isn't just a philosophical or political stance, it's also a practical one:<br>having worked at GitLab for quite a while, splitting a product into a<br>proprietary version and open-source fork (ish) introduces various technical<br>challenges that I just don't want to deal with again.<br>Which brings me to an idea I had, one that probably won't work out but that I<br>feel is worth sharing anyway; or at least one that's worth writing down so I can<br>get it out of my head.<br>The idea is pretty simple: the product is open-source, licensed using a strict<br>license such as the AGPL, optionally dual-licensed under a commercial license<br>for those two companies that are allergic to the AGPL but somehow are willing<br>to pay for a commercial license. The source code exists in two repositories: a<br>private repository where all development takes place, and a public mirror.<br>The public mirror is only updated periodically (e.g. every three months), except<br>for when something warrants an additional update (e.g. a critical security<br>vulnerability for which it wouldn't be ethical to delay it by three months).<br>The private repository is also where the bug tracker resides and where users can<br>submit patches...