A Crowdfunding Model for Browser Features

Web developers frequently find themselves wishing a particular CSS or HTML feature were more widely supported. The typical advice is to use the feature, discuss it, and file bugs with browser vendors. But what if there were a more direct route? Open-source consultancy Igalia is experimenting with exactly that: a crowdfunding model that lets the developer community pool money to pay for implementing specific web platform features. The project is called Open Prioritization, and this article draws on an interview with Brian Kardell, Developer Advocate at Igalia.

How Open Prioritization Works

The core idea is simple: Igalia curates a list of features — all already implemented or in active development in at least one browser engine — and the community decides which ones to fund. Contributions are managed through Open Collective. If a goal is met, the feature gets built, making it cross-browser and more broadly usable. The initial candidate list includes:

  • CSS lab( ) colors in Firefox
  • :focus-visible in WebKit/Safari
  • HTML inert in WebKit/Safari
  • Selector list arguments for :not( ) in Chrome
  • CSS Containment support in WebKit/Safari
  • CSS d (SVG path) support in Firefox

For each feature, the Open Prioritization website details the scope of work and how funding will be applied.

Why Igalia Is the Right Team for This

Igalia may not be a household name, but its work is already woven into the browsers most developers use daily. In 2019, the company had the second-highest number of commits to both the Chrome and WebKit source trees. If you use CSS Grid Layout, you've already benefited from their work: an Igalia team, not browser-internal engineers, implemented Grid in Chrome and WebKit. That track record matters here. This isn't about raising money and hoping someone picks up the work; it's about funding a team that has proven it can deliver these kinds of implementations and that already maintains working relationships across all major browser engines.

Will Browsers Accept the Code?

The selected features are non-controversial in terms of their specification and implementation intent. Igalia has already discussed each one with the relevant browser teams to confirm they're viable projects that simply haven't been prioritized internally. There is precedent for this model: the CSS Grid implementation in Chrome and WebKit was funded by Bloomberg Tech, which was frustrated by the lack of support and paid Igalia to develop the feature over several years. Both browsers accepted the contribution without issue. Since browser vendors value interoperability, there is little downside for them in accepting funded, standards-compliant implementations that someone else is paying to build.

Why Browsers Don't Just Do This On Their Own

It's tempting to wonder why large companies like Apple or Google don't simply fund these features themselves. Kardell cautions against that assumption:

“People might think, for example, ‘Apple has all of the money in the world’ but this ignores complex realities. Apple’s business is not their Web browser. In fact, the web browser itself isn’t a money-making endeavor for anyone. Browsers and standards are voluntary, they are a commons. Cost-wise, however, browsers are considerable. They are massively more complex than most of us realize. Only 3 organizations today have invested the many years and millions of dollars annually that it takes to evolve and maintain a rendering engine project. Any one of them is already making a massive and unparalleled investment in the commons.”

Browsers already invest heavily in ambitious internal projects — he points to Firefox's work on Servo and Google's LayoutNG — but those efforts are aimed at platform improvements that benefit many features at once. The internal prioritization of what gets built next won't always align with what developers need right now. Crowdfunding is a way to make needs heard in more than words.

This isn't dissimilar to buying a plugin for a CMS. The core team stays focused on the platform's stability and fundamentals, while third parties fill specific gaps. Open Prioritization essentially offers a similar path for the web platform: a way for developers to economically signal that a particular feature is worth building and get it over the line.

Complementing Existing Efforts Like Web We Want

Projects like Web We Want, which SmashingConf has supported, ask developers to pitch new platform ideas in open discussion. Those efforts ask an unconstrained question: what do you want the platform to become? Many answers are aspirational and don't yet have a specification, let alone an implementation plan. That's valuable work, but such ideas are nearly impossible to price or schedule accurately.

Open Prioritization is deliberately different. Kardell illustrates the distinction:

“if you asked me what could make my house better I could name a million things. Some of those aren’t even remotely practical, they would just be really neat. But if you said make a list of things you could do with a budget for what each one costs — my list will be considerably more practical and bound by realities I know exist.

At the end of the month if you say 'there is your list, and here is $100, what will you do with it?' that’s a very direct question that helps me accomplish something practical. Maybe I will paint. Maybe I will buy some new lighting. Or, maybe I will save it for some months toward something more costly.”

Features in the pilot list already have specifications and some prior implementation, so they fall within a reasonably knowable budget and timeframe. By contrast, something like container queries — which is mentioned in the project's FAQ — is still at an early discussion stage and can't yet be given a monetary value.

Getting Involved

Full details on the process and fine print are available in the FAQ on the Open Prioritization site. This initiative gives developers a hands-on way to steer the web platform's direction, alongside reaching for APIs in progressive enhancement, filing bugs, and participating in standards discussions. Web developers rarely have a direct financial voice in browser development; Open Prioritization aims to provide exactly that.