Yesterday Tom Coates posted on Google+ about being impressed and compared it to Pownce (moment of silence).

I wrote the following as a comment on Tom's post and then realized I should have just blogged it so here it is. Viva la IndieWeb!

Tom is spot on with the comparison to Pownce. What if Google (instead of Six Apart) had bought Pownce? Would it have been too soon? Did Google need to learn from the failures of Wave and Buzz in order to design/build G+?

Tom also said (in the comments of said G+ post)

"Don't even get me started on Federation. Don't. Even. Get. Me. Started."

I'm liking the term Federation less and less because it's the wrong focus/framing.

Friends matter more than Federation.

Tom goes on to wonder about social network splintering:

"I'm actually interested to know what happens if a community splinters. What happens if Google+ is successful. Do all social services get a little worse / emptier?"

About what happens if Google+ is successful and/or splinters other communities: while the straight up "we're a better version of the thing you're using [AKA Facebook]" approach appears to be Google+'s initial implicit messaging, that's merely the opening salvo.

They've led with a decent UI and that's the right approach to quickly gain users, fans, and attention (not going to say "buzz", oh drat too late), and data export from day 1.

My prediction: At some point they're going to flip-on real-time open data flow (e.g. ActivityStreams + PuSH + Salmon or some simplification thereof), so you can get your freshest data out (and in) in real-time. This is fundamentally different in nature from simple static data exports.

This will enable #indieweb sites to fully participate in Google+ while owning content on their own independent sites without having to write code for a snowflake API/TOS - something which no other silo has done yet (Buzz, Cliqset, Statusnet got/are close).

At that point I have a feeling the open network effects will be unstoppable. You'll get everyone joining that one open network - rather than splintering among silos.

Google+ still has to launch this real-time open data flow support of course, so there's a window of opportunity for Facebook or even Twitter to do so first, but I have a feeling that being the newest network, Google+ will be able to do so faster.

However, I wouldn't underestimate what a competitively motivated David Recordon, Paul Tarjan and co-workers could ship first, so Facebook has a chance (and they've shown in the past they can respond quickly). In contrast Twitter is horribly bad at shipping new features in any sort of timely fashion (e.g. they can't even ship a "who favorited my tweets" feature and whole other sites e.g. favstar.fm have had to do it for them), nevermind actually respond to competition.

The space of social network silos just got a lot more interesting. It's going to be a fun summer.

Afterword: I signed my comment on Google+ with "tantek.com" and noted: Once Google+ turns these kinds of external person references (e.g. tantek.com) into a one of those light blue + links e.g. +Tantek Çelik (Hint: it's as easy as doing a quick representative hCard discovery/lookup and grabbing the 'fn' property), then you'll know it's game-on.

Last year I wrote a brief post on What is the Open Web? in which I listed open web standards as a key component, web standards that are:

• openly documented on the web itself
• freely accessible with no charges to view or download
• unencumbered by patents, e.g. patent-free, or available under unconditional royalty free licenses (like CC0 and OWFa 1.0).

These are good high level requirements for evaluating a finished web standard, but provide only clues for what went into it and how it was developed.

You can judge a piece of apple pie by its appearance, texture, flavor and other finished qualities, but you have no idea what ingredients went into it. Were the apples organically farmed? How about the flour? What kind of oils or butter were used? Any preservatives or corn by-products?

Or how was the pie prepared? Was it mass-produced in an industrial oven? Crafted by a neighborhood bakery? Or lovingly made by a friend or relative? Just as there are good ways and bad ways to bake an apple pie, there are good ways and bad ways to develop open web standards.

There's a whole spectrum of ways to develop open web standards that's expanding over time as we learn new practices both good and bad. We can and must always strive to be better at it. We've significantly evolved our best practices over the past couple of decades, and yet we must stay ever vigilant against bad faith behaviors, both known and novel.

Here is a list of good practices, many gleaned from my personal experiences with various open standards groups and communities. The presence of these makes a standards effort more open, the absence, less so. You might recognize some/most items on this list from my previous post which explained their historical relevance to the CSS Working Group.

This post explores some of the how and why of these emergent practices, patterns, and some examples of corresponding anti-patterns. Suggested additions welcome.

1. develop it openly.

   This may be the most important aspect. You might not consider every idea or brainstorm worthy of publishing publicly on the world wide web. That's ok, understandable, and maybe even shows humility. Instead you're more comfortable sharing an idea privately with a few friends or colleagues, maybe even at a private event. No problem, take notes. The instant you've received enough feedback sufficient to convince you that you might have something worthy of consideration, even (perhaps especially!) before you've implemented it, publish it on the public web. On a wiki or a blog. Sharecropped on a content hosting service or on your own site (preferred). As plain text or rich semantic HTML (preferred). Whatever and however, just put it somewhere on the public web with a permalink.

   Anti-pattern:

   Resist the temptation to develop an idea until it's "complete" or until you've got other companies to sign-on - i.e. avoid the trap of "delayed open" development or duopolistic/oligopolistic announcements. Publish your ideas early and ...

2. iterate openly.

   Whether you publish your standards brainstorm ideas on a blog, a wiki, or check them into github, iterate on them openly. Publish, save, commit new versions with any degree of stable improvement over current versions. Keep old versions and a public interface to access them all. Preferably make sure each version has its own permalink. This provides greater transparency and visibility into the thinking behind a standard, its current state, and how it got there (provide at least minimal check-in / edit summary comments with each change). Even small edits reflect activity, attention, stability/flux and are thus quite useful.

   Anti-patterns:

   As convenient as it may seem, avoid simply updating a static URL in place. It's ok to have a "give me the latest version" URL, but only if you can also access specific iterations at their own date(-time)-stamped permalinks. Avoid the temptation to wait until each iteration feels "complete" (kind of a "delayed open iteration" problem). Avoid deleting older revisions just because they're "old" - people may have linked to them, and often early changes provide insight into why things ended up a certain way.

3. use an open wiki.

   I have Kevin Marks to thank for first suggesting that we write-up some of the early microformats on an open wiki. I was skeptical at first, being used to W3C's more formal specification process. Starting with XOXO (fairly sure that was the first wiki-based microformat) we've used wikis to conceive and iterate. Some microformats like rel-license, hCard, and hCalendar started as brainstorm presentations and blog posts, but were quickly captured on wiki pages and iterated there since. Wikis are also good for documenting research, examples, and even decent for issues, feedback, and capturing multiple points of view. In general it's best to use wikis for all content related to your standards effort. Be sure to allow anyone to trivially create an account or use an OpenID to login. You may want to consider disallowing anonymous edits as the resultant spam can overwhelm a new wiki that has few contributors/gardeners. Finally, having an "Edit" link/button as well as a browsable history on open standards sends a profoundly strong message of community accessibility, accountability, and participation.

   Anti-patterns:

   Avoid creating a private wiki for an open standard. Avoid using a single account for edits (make everyone use their own account - this helps accountability). Avoid bureaucratic sign-up processes - the reason you put things on a wiki is to make it easier for casual readers to participate. Don't force users to read pages of bespoke legalese etc. just to create an account to contribute. Use standard licenses and contributor agreements such as CC0 and OWFa CLA 1.0 which casual readers can accept (or not) based on previous evaluation.

4. discuss openly.

   In addition to blogging and/or tweeting etc. publicly about your potential standards ideas, discuss them publicly. Start with existing applicable public wikis, mailing lists and/or IRC channels (preferably both) rather than creating new ones.

   Anti-patterns:

   Minimize private discussions. Sometimes, even with iterations, you want to bounce an idea off of a trusted colleague, which is a completely sensible thing to do. Regardless, minimize them and don't fall into the trap of preferring private discussions because you're afraid of public criticism. If you do have a private meeting, document the outcomes or results promptly. Finally, avoid prematurely creating a new list or IRC channel. Rarely is an idea worthy of its own forum. However, if/when the need arises to create a new group...

5. open email list and IRC channel.

   (create if necessary). If your idea both attracts sufficient attention from others (at least two more is a good minimum) and exceeds the scope of existing mailing lists or IRC channels, you may have to create a new IRC channel and mailing list. Make them open for anyone to join, preferably requiring open contribution agreements, e.g. CC0 and OWFa.

   Anti-patterns:

   Do not create a closed list or IRC channel for discussing an open standard (sounds obvious but you'd be surprised how many times people keep doing it).

6. open IRC logs.

   When discussions happen in IRC, sometimes people say useful interesting things that are worth citing. Set up a bot to (auto-)join the channel and log the channel somewhere on the public web with permalinks at least for each day, and preferably for each line of communication. This helps encourage creative thinking in the low-barrier to participation environment of IRC (think/type) knowing that the ideas won't be lost.

   Anti-patterns:

   Avoid requiring a login just to read IRC logs. Avoid blocking search engines from indexing IRC logs.

7. open list archives.

   Provide open access to mailing list archives, without requiring any login, and indexable by search engines. Ideally provide a user interface to search the archives. Similar to IRC, sometimes ideas originate or issues are resolve on mailing lists, thus it helps to cite those messages as well.

   Anti-patterns:

   Avoid forcing users to login or join a list just to view the archives. Avoid blocking search engines from indexing the archives.

8. send wiki edits to IRC.

   I learned indirectly from folks active in the Wikipedia community that's it quite useful to have a bot that watches for wiki edits and summarizes them realtime in a community IRC channel. We implemented such a bot fairly early in microformats.org's history. Most recently Aaron Parecki setup the Loqi bot to monitor changes from the microformats wiki and report them to the #microformats IRC channel. It's great for (more) quickly catching spam or other vandalism and reverting it. More importantly the bot provides a nice sense of what wiki pages are receiving more attention, and each such update provides a implicit invitation to participate on the wiki.

   Anti-pattern:

   Avoid using URL shorteners to abbreviate MediaWiki (or other) wiki diff URLs.

9. open test suites.

   Every time I've seen a test suite published publicly for a standard I've seen both the standard improve, and more importantly the interoperability and completeness of implementations improve. Start with at least one simple test per feature (e.g. element, attribute, property, value type) and then expand combinations, edge cases, and error tests from there. Be sure to publish the test suite just like the specification, with versioned permalinks and open licenses like CC0 and OWFa. You want to encourage people to copy existing test cases, make variants, and publicly share them.

   Anti-patterns:

   Avoid private or payment required test suites. Avoid requiring logins to view test suites. Avoid browser sniffing on test suite tests.

10. open implementation reports.

    A test suite helps exercise features of a spec but interoperable implementations are what really prove them out. Publish the results of running an implementation thru a test suite so that others can verify it for themselves. It tends to also help motivate other implementers to keep up. Be sure to link from such reports to the specific version of the test suite used, as well as noting the specific product/implementation version (preferably with download URL).

    Anti-patterns:

    Avoid summary-only implementation reports - always link them to the detailed reports from which summaries were derived for verifiability. And similarly to above, avoid private or payment required implementation reports.

Adopt those ten practices and you'll find that you develop open web standards that are both of higher quality, and often faster as well.

Despite the "10 Practices..." title of this post, there's one more that's worth taking it to 11.

11. openly encourage broader community involvement early and often.

    While it may be easier to reach some form of "consensus" by working by yourself, with a couple of friends, or as one of a few large companies, standards efforts which actively encourage community involvement tend to be better, and more open as a result. Reach out early to the folks you think would use your standard, those that would author, develop, debug, and test, especially in related communities. Let them know what you're working on, and how to lurk or contribute to your efforts.

    Anti-patterns:

    Avoid falling for the lone inventor in the garage myth. If you think you can do a better job inventing something privately in your garage, or behind your corporate firewall, these days you're almost certainly wrong. This didn't used to be the case, and thus we have numerous industry origin myths about the one or small number of inventors that went off and did something novel. These days, the open web is evolving and iterating much faster than any one individual, company, or even a small number thereof can do by themselves. This is a new phenomenon since the advent of web search engines of the late 1990s / early 2000s, and the subsequent greatly increased discoverability (and thus faster feedback loops) of innovations occurring in the open, on the open web, and in the past five or so years, in real-time.

The above practices, patterns (and anti-patterns) are based on personal experiences (both good and bad) with existing open standards communities and organizations such as W3C (whose working groups vary wildly in the implementation of the above), IETF (same), microformats.org, WHATWG, and Activity Streams. In fact, it would be interesting to see a table of various open standards efforts, with columns for each of the above good practices, noting which communities do which things well, and which things they could improve. Good material for perhaps a future blog post.

Developing good open web standards is more often than not an arduous, tedious, extremely detail oriented, and quite unglamorous task - it's work that typically induces blank stares when provided as an answer to questions like: "What do you do?" or "What do you work on?".

The moments of recognition for open web standards are few and far between, and thus it's important to take note when those moments occur. This is one of those moments: Cascading Style Sheets Level 2 Revision 1 (AKA CSS 2.1) and CSS Color Module Level 3 (AKA CSS3 Color) have finally become W3C Recommendations.

Each and every person who edited, contributed, wrote test suites, ran test suites, wrote implementation reports and perhaps most importantly, diligently interoperably implemented these standards deserves significant kudos for helping advance the open web. And along the way to the CSS 2.1 Recommendation, the CSS Working Group learned, developed, and adopted a number of open standards practices that as a set may prove to be far more valuable to the future of the open web than any one specification.

---

I don't think I had any idea what I was getting into, nor how it would shift the course of my professional career when Chris Wilson suggested to me just over 13 years ago that I join the W3C's Cascading Style Sheets Working Group (then actually known as "CSS&FP" - The FP for Formatting Properties) as Microsoft's Alternate Representative. In May of 1998 I attended my first CSSWG meeting (first open standards community meeting of any sort, W3C, etc.) in Paris, France hosted by Daniel Glazman of EDF. It felt like I was participating in some sort of geeky international congress (still kind of does actually).

Two months earlier, in March of 1998, CSS 2 had become a W3C Proposed Recommendation (PR) which meant that it was considered "done" and was simply awaiting a procedural W3C member review and vote. For all practical purposes, nothing else was going to get fixed in CSS 2. There wasn't a Candidate Recommendation (CR) phase back then, as evidence by the fact that no-one (including my Tasman team as part of Microsoft Internet Explorer 5 for the Macintosh) was able to implement CSS 2 as specified. The problems in CSS 2 were far more severe than mere errata - we had to develop a full revision to fix it.

It took us, the CSS working group, four years to produce the Last Call Working Draft of CSS 2.1, the publication thereof which was part of my first blog post. And that was merely the first of many so-called "Last Call" working drafts, which served to convince me that the very concept of a "Last Call" was fundamentally flawed - but that's a subject for another post / discussion on pragmatic specification stages.

The long and exceptionally challenging path to CSS 2.1 interoperability (several cycles of extremely thorough diligent testing, editing, iterating) among other things has taught us some key things. First, that holding a web standard to openly published test suites which are interoperably implemented by web browsers is absolutely essential for practical, pragmatic standards that are usable on the web, rather than hopes and ideals of what could be (what most published "standards" appear to be). However, second, it's also taught us that it can take a long time to be that thorough with something that large.

From the first CSS 2.1 Last Call Working Draft to Recommendation it took the working group nearly nine years. When Ian Hickson estimated it will take til 2022 for HTML5 to reach Proposed Recommendation, it wasn't unreasonable: that's 10 years from next year (2012), when HTML5 is now expected to reach Candidate Recommendation. And HTML5 is much more complex than CSS 2.1.

This is also why the CSS Working Group chose to modularize CSS for CSS3 - which also took several iterations of editing, implementing, remodularizing to help figure out where pragmatic boundaries could be drawn. Modularization is one of those things that can seem both reasonable and straightforward in theory, but in practice, be quite challenging. The CSS Working Group has made progress with understanding practical modularity, as evidenced by several CSS3 modules having already reached Candidate Recommendation status, and reasonably well implemented in browsers.

---

However I'd like to close this post with what I think is the more important set of lessons, expanding the first learned point above. In particular over the past 10+ years that it took us to make CSS 2.1 real, we've learned the following practices are strongly effective ingredients for open standards development. Some/many/most of these practices are not (or no longer) unique to the CSS working group, but it's one key group at W3C that's implemented them all and did so quite early on.

Open Web Standards Practices

• open iteration. The CSS working group was among the first to publish and maintain public interim editor's working drafts. Anyone can browse the raw updates: dev.w3.org/csswg. I don't remember who started this convention at W3C, but I highly approve.
• open mailing list. The CSS working group decided quite some time ago to switch all CSS spec discussion from the member-only w3c-css-wg mailing list to the already public www-style mailing list. The member-only list is pretty much just used for administrivia now.
• open irc channel. Since as long as I know, the CSS Working Group has used irc://irc.w3.org:6665/css for teleconferences plus face to face meetings, and anyone can join in to lurk, offer commentary etc.
• open irc meeting logs. The CSS working group for several years now has published public logs of the IRC channel from meetings (teleconferences, face-to-face). This is one I personally pushed for, based on my experience with the utility of having public IRC logs for microformats.org.
• open wiki. The CSS working group was among the first at W3C to create an open wiki. It's on its own site wiki.csswg.org, created before wikis had really been adopted inside W3C. Again, something I pushed for (but I believe Elika implemented, got the domain, set it up etc.) based on my experience with wiki-based development on microformats.org.
• open test suites. Even with CSS 1, the CSS working group produced open, freely usable online test suites. This seemed like an obvious thing to do to me at the time, but apparently was not something to be taken for granted in standards development, e.g. absent from typical IETF work. For example there was no public iCalendar (was RFC 2445, now 5545) test suite. Instead, implementers were expected to pay for and attend in person an Interoperability Test Event run by another consortium (not IETF). This isn't just history, there still is no online, public, free iCalendar test suite. But you're welcome to register for the upcoming October 3-5 2011 CalConnect Interoperability Test Event taking place in Prague, Czech Republic and pay over $2000 to participate. Just want to observe? That'll be $350. No joke.
• open implementation reports. Anyone is welcome to run an implementation through a CSS test suite and submit/publish an implementation report. After some degree of (minimal) verification it will likely get posted on the W3C's site, openly, viewable by all. Again, not to be taken for granted. Again in contrast, CalConnect Test Event Reports public reports will not identify any participating organization with any particular set of results..

In my opinion, as of 2011, if you want to develop open standards, especially open web standards, you must at a minimum follow the above practices. I'll expand on why and patterns that have emerged in a subsequent post.

CSS 2.1 is a tremendous achievement and everyone who worked on it, implemented it etc. should be very proud for this key building block of the open web platform. But we've gotten a lot more than CSS 2.1 in the years it took to develop it - the deliberate open standards practices that have emerged from that effort (among others) are perhaps even more valuable, as they can inform and improve every other open web standards effort that we pursue, as long as we deliberately choose to do so.

One year ago today I started contracting with Mozilla to help advance open web standards.

I'm reasonably happy with what I've accomplished in the past year (e.g.: CSS3 Color to PR, HTML5 improvements, a modern GENDER property in vCard4). I'm thankful for the inspiration and support I have received from the people and culture at Mozilla. There's an incredibly high density of pragmatic positivity as well as the constant background hum of the ongoing fight for a more open web.

While I've made progress with specifying details of bits like how 'text-overflow' works in numerous edge cases, there's a lot more to be done at a higher level to advance web application fidelity. Some of my colleagues like Alex Faaborg and Alex Limi have been thinking a lot about how to do so from the user interaction perspective and I'm looking forward to working with them more to capture such details in open web standards specifications.

For anyone who wants to work on "the open web platform", I can hardly think of a better place to be. Have ideas for improving open web application fidelity? Add it to my Mozilla projects inbox and I'll see what I can do.