The Web Standards We Need: Part II — “Guilds” (CGs++)

--

This post is the second in a series discussing how we can help arrive at the Web Standards We Need. In the first post I examined why developers remain largely uninvolved in the standards process, even in ways that they could, technically be and how we might change that. In that post I introduced a new concept/pilot program we are setting up called “Chapters” which provides some ways to help tighten the feedback loop and provide more interest and education. In this post, I’d like to talk about how we take this a little further and help navigate the existing processes and bodies along the way.

For a while now, W3C reformers have been pushing the idea that developers need an actual voice in the W3C. The frequent counter points are that most work takes place in public (each group has a public mailing-list and IRC channel), that developers are free to participate and that W3C has many Invited Experts who participate in member only working group events, and that the W3C now allows the formation of Community Groups which provide a lot of opportunity and have shown some good success.

All of these counterpoints are true — so what’s left to discuss?

What isn’t working with the status quo?

The W3C itself is pretty much driven by membership. Ultimately, decisions about the goings on, the larger vision, how processes should work, what kind of licensing we need, etc of the body is derived through the pulse of AC (Advisory Committee) representation. Each member organization has one representative called an “AC Rep” with special powers: The ability to comment, discuss (and be taken seriously by default) and actually vote on matters, as well as the ability to name participants to working groups. Member orgs are also expected to donate participation, meeting and work time and travel expenses for anyone their AC nominates.

While the existing systems do have some good qualities that allow the most dedicated external technical contributors to do so without paying for membership, it is very hard to operate externally — and they do it all at their own cost. The Responsive Images Community Group is probably the poster-boy for external success, but it was hard fought and long. The design of standards is such that it provides no effective way to help the organization (any of them really, but specifically I am talking about W3C here) get the pulse of developer interest, because there are is no equivalent representation in the AC — this further underscores the idea that these are “external” and creates a de-facto exclusionary posture which is alienating.

So how can we fix these problems?

One proposal intended to help was created by a W3C Task Force. It was called (unfortunately) “Webizen,” which would allow individuals a kind of limited membership for the bargain price of $100 per year. For the this, every N developers would be able to elect a kind of limited representative who could vote in elections, communicate with the ACs, but not actually appoint to Working Groups. The idea was to establish a kind of electoral college with an upper and lower house of representation.

Membership, who — again — speaks through the ACs, basically declined this proposal. They asked the task force to formulate a new one. Interestingly, AC comments are not really allowed to be made public, so really, only ACs, AB, CEO or Director can know exactly what was discussed— the best the task force can get is a rough third-party summary. This makes building a good proposal very hard.

A Loophole?

Actually, it’s not a loophole, it’s just how the process works: Today, any legal entity who pays the dues can join today regardless of whether that group is a giant multi-billion dollar venture like IBM, Apple, Google or Microsoft, or a tiny non-profit, or even a sole proprietorship with a single employee — and they all get the exact same rights and say.

In theory then, developers could form orgs — guilds or something — as legal entities and it would seem, problem mostly solved. They could elect a representative, amortize the cost of travel or even development across N members, accept donations or offer reasonable dues — just like a lot of members do — and I expect we’d see very good things.

So why don’t we?

Well… It turns out that setting up a legal entity is non-trivial: It costs money, it requires process, there are legal and monetary ramifications. If you think I’m making too much of it let me make the point a different way: At 20 years old, the W3C itself is still not a legal entity. Further, creating several according to similar models raises the question of whether they are affiliates which might harm their ability to individually join, etc.

It’s relatively easy for a business or organization who has created a legal entity for other purposes to use that as a badge to get in, but at the end of the day, this requirement is simply a tax preventing a looser collection developers from doing just that. That’s too bad too, because it could help the W3C (and the Web in general) in very practical ways.

So here’s my proposal…

  1. Get rid of the requirement to be a legal entity and provide a means to establish virtual orgs (CGs++) which are acceptable in the same way as any legal entity.

That’s it. Then just treat them like anyone else.

You see, Community Groups already provide many necessary underlying raw materials that you’d need:

  • Founding document
  • Concept of Membership
  • Affiliation disclosure
  • IP / Release agreements
  • Ability to collect votes and elect chairs
  • They even have a blog and wiki and IRC.

Really the only thing lacking is a means to collect funds and utilize it which can get complicated with an ‘org’ — so my proposal here is simply that W3C allow membership for a specific guild/CG++ to come through channels like kickstarter without going through a middleman — this neatly sidesteps (I think) the difficulties incurred by an org itself directly collecting or holding money.

Because of this design, different org formulations can compete by simply altering their description or in the founding documents. This means it’s possible for a guild to state their intent to collect money to do things like fund an elected developer’s participation or travel, or to write tests or send feature pull requests. These would follow the same model — first choose what you want to do, then fund it directly. It’s easy to think of ways that scores of interested developers could collectively “unionize” (in an abstract sense — their collective bargaining power) and contribute as much or more than many current members — simultaneously getting rid of the exclusionary by default and lack of means to get a pulse from developers all in one swoop.

So that’s what I’d like to see, if you agree, contact your representative and ask them to…

oh… wait… You don’t have one.

In lieu of that then, just share this post and say something positive.

--

--