There’s been a lot of efforts over the past years to give Web developers more of voice in shaping Web standards. Despite that, not much has changed. Taking in account dev requirements and needs is still the exception. It should be the norm.
To have more weight within the platform, Web devs need to self-organize and drive change. A good example of that is what happened with the <picture> element and @yoavweiss’s work. Edgeconf is another interesting example. We need more of this. I’ve tinkered with (and discussed with some of you) the idea of creating something akin to a developer’s guild. Thanks notably to membership dues, such a guild would be able to drive implementation of features within browser engines, maintain projects such as this one, write tests, participate in standards meeting, etc. in a sustainable, long-lasting way.
I haven’t really thought through this more at the moment to be honest. I’m aware it’s a substantial endeavor, but our community is broad and with sufficient interest, it might be doable.
My post this morning is listed as “Part I” - there is a “Part II” as well which is about this as well as some integrated standards politics. I’ve been thinking on this quite a bit, had some conversations (off the record) with some lawyer friends and others and even some folks at W3C. It is a substantial endeavor, but I think there are potentially some shortcuts that can simultaneously make it more pragmatic and further the degree to which this endeavor is taken seriously by standards bodies. I’d like to post it up tomorrow, we’ll see.
As you know, that’s a topic that I’ve been thinking about for a long while. I’m all for it.
This site was a first step, but even though it has so far been relatively successful it was clear rather rapidly that it was not enough. Once people have hashed out the early steps of an idea here, they don’t have anywhere to go (unless they are already well aware of the tangled mechanics of standards — which defeats the point).
My next step is to set up a place that friendly and easy for people — anyone — to create and develop specs. It is not meant as an xkcd:927 competitor to W3C/WHATWG/TC-39/IETF but rather as a complement. The basic idea is that you can have your spec there, it gets published at a predictable location, the community knows what to watch, the toolset is regular and well documented, and a pipeline can be created to any other org.
I hope to have the basics up by the end of the month.
This isn’t a counter-proposal to a guild. We need both. But I think that the two tie in nicely together.
I have been thinking about it for some time now, and I agree that some sort of organization would make a lot of sense (the word “guild” gives me the chills tho ), assuming that enough developers care enough about the subject. I think that “giving developers a voice” through a proxy is probably a good idea. Some sort of voting system to determine prioirities and gather feedback would also be good.
The question is, how many developers is enough for this to be interesting? The RICG which is an extremely high-profile standard effort, has about 300 CG members and 3.5K twitter followers. On the one hand, that’s a lot of devs, but it’s also a very small percentage of them.
As Brian said in his post, I think most devs don’t think that this is something that they can/should do. Can this be changed?
And then there’s the (literally) million dollar question: How many developers are willing to put their time/money into this? Will larger Web companies and agencies be willing to chip in either man hours or money into such an organization?
You’re talking about:
which is exactly what it takes, but also takes a lot of money to pull off.
I was just thinking about this, and how the current mood I’m getting from the WHATWG, toward only speccing async Promises-based APIs (as I just complained about in WebCrypto), feels a lot like the bad old days of W3C everything-will-be-well-formed-XML ivory tower specifications. (While UAs are steering the ship this time, the end developers are getting just as shafted - leaving new specs to get ignored just as thoroughly.)
We need more representation for plain old programmers doing plain old sync code.