Helping Move the Web Forward: The UI Fund
It is a universal truth that one’s time and energy are, unfortunately, limited. We have to priotize how we spend it. I’ve talked a lot this year about how implementation funding limits bottleneck standards, but there are other important kinds of limits too. In this piece I’ll talk about one of them, and an exciting new development to help it from the Chrome team.
The truth is, lots more people would love to help move the web forward in some way, but their budgets of “free” time and energy are small. As a result, many potentially good things just don’t happen. Lots of critical stuff that does happen ultimately winds up being unhealthy for people who began work as a labor of love.
Efforts toward potential stanardization are especially hard in this respect. Ultimately we need lots more web developers to be involved in finding the ways we move the web forward. In the end, they’ll provide the fitness test anyway But, the truth is, that while we can (and have) made our processes and efforts theoretically open, the kind of sustained attention and efforts that standardization requires are implausibly difficult without the support of one’s employer.
That’s why I was pretty psyched to read this post about Chrome’s new UI Fund by my friend Nicole Sullivan. It aims to add some grant-based funding toward regular people doing lots of the work that helps move the Web forward.
I think this is an amazingly great idea that I’m excited to watch develop. I feel like it is very spirtually aligned with our Open Prioritization efforts - finding ways to invest in the under-addressed parts of the platform and ecosystem that need it.
The hard economics of developer involvement
Why am I so excited? Standardization operates on a timescale completely foreign to most developers. It requires long, sustained efforts and massive coordionations of time and attention where things move forward in fits and starts as planets align. The value proposition is an all-or-nothing reward that might pay off only years down the road.
This is a problem that has intrigued me a long time.
I’ve been very keen on reimagining standards as a more natural process, most of which didn’t happen in a committee. I believe this could help address the economics on both ends of it. I have tried to help imagine a number of things here to imagine better involvement and lower barriers.
Robin Berjon and later I created a discourse instance we called “Specifiction” which tried to help with some of this. Later, with the jQuery Foundation I helped the (now defunct) chapters.io to try to engage developers directly. I’ve been involved with things like WebWeWant and the WICG.
Most recently I’ve been a part of Open UI - a kind of “supergroup” within WICG focused on UI Components.
There’s a lot I like about it. First, it’s not all or nothing failure. It doesn’t make assumptions about standarization. Stanadrdization into the platform itself is, we hope, a possible outcome for some thing - but there are lots of value points along the way in shorter timeframes which can potentially help shape the broader ecosystem. Its first aim is research, which will serve any library going forward at all. It’s a good place for ideas to begin to coalesce and have critical questions asked along the way to keep things on a path that could be easily paved. It should help libraries align, and hopefully shape thought and conversations in the work we all do.
But… It’s still a lot of effort.
What I learned along the way…
What I found along the way is that all of my efforts to shape a process change the calculus somehow in useful ways, but the fundamental time budget/funding issues don’t really go away. In practice, things are moved forward by people who show up and find effective ways to move something forward. That is already terribly hard for the people who work for browsers, but consider what a head start they already have here. First, they have a ton of deep background and insights gained from the fact that they are deeply plugged in. They know about past efforts, related work, engine internals, gotchas to avoid and so on. Thus, they can use their time comparatively efficiently.
It’s probably worth noting here how many of those people tend to not be keen to start efforts sometimes. This can be frustrating and time consuming. A lot of it is not in your control. Ideas don’t pan out, even for them - and that can be terribly frustrating and demoralizing if you have personally invested a lot.
… And remember, they’re getting paid for it.
How much more then is this asking of someone who isn’t? The truth is, significant developer/designer involvement is kind of disadvantaged from the start and only gets worse.
One improvement might be to sponsor or at least incentivize continued involvement. That would be a lot healhier and maybe make this more plausible.
So check out The UI Fund - and I encourage you to look into this if you’re doing work already and not getting paid, or to look into getting some sponsorship for that stuff you’ve always wanted to try getting involved with.