I recently accepted an invitation to join the Haskell Foundation Board. For most of the last decade I’ve been trying to make Haskell work commercially: finding projects where it makes sense, convincing companies to try it and hiring people to write it. Serokell has funded GHC work along the way too.
A lot of that time went into watching where adoption gets stuck. The Haskell community has plenty of people who understand the language deeply, but far fewer companies that have spent years having those commercial conversations. That experience is what I’m bringing to the Board, and it’s the perspective I’m sharing here in my personal capacity, rather than speaking on behalf of the Haskell Foundation.
Why it’s hard for companies to fund the Foundation
Earlier this year the Foundation decided to put most of its money into technical work and to make it clearer how contributions turn into improvements in the ecosystem (see the May 2026 update). I agree with that direction. But it’s about how the money gets spent, and it doesn’t do much to persuade companies to provide it in the first place.
Imagine a company with twenty Haskell engineers whose builds are slow enough to waste a noticeable part of their week. Inside the company the problem is easy to explain, because someone can put a cost on it and take it to whoever controls the engineering budget. If that company then wants to pay for a fix upstream, it has nowhere obvious to go. The Foundation’s Bronze sponsorship starts at $15,000 a year, which isn’t much for a company like that, but the sponsorship has no connection to the problem they came with. Some companies sponsor simply to support Haskell, and I’m grateful that they do, but I don’t expect many more to join on that basis.
A few weeks before I joined the Board, I discussed this with Simon Peyton Jones, Marc Scholten and Avi Press, together with Dmitrii and Roman from Serokell. Simon put it pretty well. A company has little reason to pay for an improvement that nine of its competitors will get for free, but it may be perfectly willing to pay a tenth of the cost if the other nine pay the rest. Getting those ten companies to the same table is hard for any one of them and a natural job for a foundation.
In practice I’d begin by bringing companies that use Haskell together on a regular basis, without asking them to become members first, and asking what’s actually getting in their way. The problems that can realistically be fixed would then go into a simple public funding directory. Rust launched something very close to this in 2026 (their Commercial Network), which costs nothing to join and is tied to a Funding Directory where companies can pick work to support with money or engineering time.
Turning problems into projects someone can pay for
For this to work, the things we ask companies to fund have to be specific. A general request to support the ecosystem is hard for anyone to approve, whereas a request to bring build times on a set of representative projects down from one number to another is something a company can evaluate. The same goes for something like a three-year commitment to maintain part of the toolchain, or a production guide that someone actually keeps up to date. Each one needs a person responsible for it and money attached to it. It also helps to agree up front what result would count as success, because otherwise nobody can say a year later whether the money was well spent.
Haskell already has a good example of this. The Sovereign Tech Fund, which is now part of the Sovereign Tech Agency, invested €320,000 in Cabal in two rounds of €160,000 in 2023 and 2024. Some of that went into architecture and long-term maintainability, and some into the less glamorous stuff — answering users, getting releases out. Someone described the work clearly enough that it could be funded. We haven’t yet found a way to do that routinely.
I think the same approach applies to promoting Haskell. Simon said on our call that we are not promoting Haskell’s advantages enough, and I agree with him, although I don’t think the answer is another list of language features. In the State of Haskell 2025 survey, 42.68% of people who answered the employment question said they don’t use Haskell at work but would like to. What helps them is material they can show their managers, and a production case study from a company in their own industry is probably worth more than anything else, especially if it’s honest about what went wrong. That kind of material can be funded and owned in exactly the same way as engineering work.
A first experiment
If I had to choose the first funded programme, I would choose build performance, although I should say this is only my guess so far. It looks like a good candidate because many companies would benefit and no single company has much reason to pay for all of it, but we need to check whether it’s actually what commercial users most want to fund.
So before asking anyone for money, I would start by measuring. We’d take a handful of real projects on fixed hardware and measure how long cold and incremental builds take. I’d also want time to the first useful error after a change, since that’s the number developers actually feel day to day. The benchmark and the method would both be public. Building and maintaining it is itself work that needs someone responsible and a budget, and it would be inconsistent of me to argue that everything needs funding and then expect this part to happen for free, so I think the Foundation should pay for this first stage itself.
Once we have the numbers, we can take them to companies that already suffer from slow builds and ask whether the problem costs them enough to put money or engineering time into fixing it. If around five of them say yes, we put a target and an estimate on it and add it to the directory. If nobody is interested, I’ll have learned that my assumptions about what companies will pay for were wrong, and I’d much rather learn that from one benchmark than from a year of fundraising. Then we’d move on to another problem, maybe production documentation or supply-chain security, or whatever the companies we talk to turn out to care about most (quite possibly something I haven’t thought of).
Risks
Directed funding tends to favour projects that are easy to explain. Build performance is easy to explain, while something like release engineering usually isn’t, even though it matters just as much. For that reason I don’t think all of the Foundation’s money should be allocated this way, and some of it should stay available for work that would never attract a sponsor on its own.
Conflicts of interest are the other obvious risk. Serokell builds commercial software in Haskell and contributes to GHC, so if the Foundation funds more engineering, there may be work we are qualified to do. I don’t think it’s a problem for people from Haskell companies to be involved in the Foundation, because the commercial side of the ecosystem is small and the people who understand it best mostly work in it. The problem starts when specific money is being allocated, and at that point the rules should be simple. Anyone with an interest says so and stays out of choosing their own company, and the Foundation publishes what it funded and why. That should apply to everyone, and Serokell should be the first to follow it.
Someone also needs to do the ongoing work of keeping companies engaged and chasing up what was promised (the boring part that decides whether any of this works). I’ve run a company long enough to know that this doesn’t happen reliably when it’s left to whoever has spare time, however capable and well-meaning those people are.
None of this needs a perfect structure before we begin. I’d like to run one programme and be honest about how it went. Being on the Board means I can now actually help with that.
.jpg)
.jpg)
