Commons harmonization, interoperability, standards

If possible, I'd engage deeply (quite time consuming!) with all efforts to create for global social technology commons.

Obviously nobody can do that :) What I mean is to avoid reinventing the wheel wherever possible (with all the fragmentation of effort and confusion that creates), especially when it comes to interoperability protocols. As AK-47 inventor Mikhail Kalashnikov puts it:

"one thing is clear: before attempting to create something new, it is vital to have a good appreciation of everything that already exists in this field. "

One of the most epics fails in this respect was Tent. They were trying to build a decentralized hosting standard as a walled garden. According to others working in that space (specifically I've been chatting with Sean Tilley of Diaspora*), they were totally disinterested in making use of existing protocols, and seemed to believe they could convince everyone to switch to their completely novel set of protocol. A textbook case of totally avoidable standards proliferation.

All the other projects in the space were either using their own protocols, or engaged in harmonization efforts through hubs like the W3C Social Web WG and the IndieWeb. Not surprisingly, Tent's expectation that everyone else would conform to their brand new roll-your-own standard went down like a cup of cold sick. The Tent hompeage (and the Cupcake demo site) are still on the web, but nobody has done any active development on them in years.

Hi @strypey and many thanks for your contributions here. I particularly appreciate the link to

Amelia Bellamy-Royds' experience working on version 2 of the SVG standards is a good example.

It's stirring stuff. Bits like ...

Meanwhile, the W3C's process meant that they needed their member companies to agree to a new charter for the SVG Working Group by January 2017, and that was looking less and less likely

and

Administration at the W3C is still trying to revive the SVG working group, but they are doing it via quiet negotiations with browser reps.

... in particular ring true to me. The W3C is controlled by its member companies, who pay a lot of money to be in the game. In case anyone hadn't noticed, they are capitalist companies. And, naturally enough, if a particular track of standards development doesn't suit their interests, they won't back it, pulling the plug from the passionately dedicated folk like Amelia.

And, I guess, for browser-related standards like SVG, it is the browser companies that matter (OK, except for Firefox).

Amelia herself says, in a comment reply (on April 21, 2017):

I never saw a tutorial "how to dive your hands in the web foundations and how to help building a better web". I wish I could help you (and I guess you are not the only one in such case).

I think this is one of the biggest problems with the web standards process. It is very difficult for individual devs and small companies to contribute, without getting sucked in overboard like I did.

There have been some efforts to open it up.

[...]

But it isn't easy. Managing a large community is job unto itself, one that gets even less respect than building open source software and open standards. You need someone to moderate and review all submissions. And you need good systems and structures and styleguides and planning documents in order for the work to be divisible into small pieces while still adding up to an effective whole.

What seems to happen (Web Platform Tests is an example) is that the people who have the time and expertise to do those things end up doing the work themselves, instead of trying to herd a community of cats into doing it.

It is these kinds of issue, highlighted by Amelia, that I would principally like to address, in discussing Commons Harmonization.

I reckon, @strypey, I agree with you on much of what you say. Let us, indeed, take heed of the projects that simply didn't work out, discuss and note the reasons, and make serious efforts neither to reinvent the wheel nor to repeat the same old mistakes. You go on to say:

If we - both as end users of the net and as developers/ sysadmins/ webweavers - engage as constructively as we can with open standardization efforts, one day there may be people saying the same about our pioneering work. Otherwise, despite our best intentions, we are building walled gardens, and eventually the open network will hack around us and leave us behind.

I don't exactly agree with this analysis. The Amelia example demonstrates what can happen in W3C. Sure, we can hope that Amelia's noble volunteer work will bear fruit, but equally we have ample grounds to fear that things that really threaten the status quo will not pass through W3C, leading to wasted time and burnout of good commoners with good ideas.

When I am advocating fixing the process, I certainly don't mean "set up an alternative to W3C that ignores everything that isn't 'the one true way'". That would indeed be utterly wrong-headed and futile. But let's look at the "cultural and behavioural dimensions to standardization" (as I said in the header) to work out a constructive approach to harmonization / interoperability that is not at the mercy of capitalist interests -- rather, that is a true knowledge commons, not just in the sense of the standards being open and free, but in the sense of being governed by a community of commoners, in the interests of the commons and everyone.

I would be really interested to hear of other people's proposals for action in that direction.

What we've done is to work outside the existing standards orgs, but collaborate with them where it fits. We can't be stopped by them, but our vocabulary and protocols mesh with both W3C and ISO standards, and we work directly with people in both standards orgs whose interests intersect with ours. Will that work? We don't know yet. Should find out this year.

To expand a bit re "will that work?":
* Will the valueflows vocab and protocols get finished?
* Will they be used?
* Will they be effective in connecting commons economic orgs into larger networks?
* Will we be able to effectively collaborate with both W3C and ISO?

The first 3 are more important than the last one. Especially the 3rd.

Re "governed by a community of commoners": we are not. We are a small group, I think by necessity. It is difficult unpaid work and requires dedication and focus. We follow consensus principles internally, but informally. We take direction from all of the various commons-oriented economic organizations that we work with, that we think might use our work when it's baked. We have not tried to set up any kind of new umbrella commons standards org, which seems to be what you have in mind.

Thanks for the comments, @bobhaugen

Completely agree, what matters is whether your standards will be "effective in connecting commons economic orgs into larger networks"; or more generally, whether any approach to interoperability / harmonization will be effective in connecting commons-oriented organisations and helping them to work together effectively and efficiently (the latter: in their own eyes, not imposing any metric!) And your first two points are also essential preconditions to that. Nicely put.

And I'm glad that you are self-consciously independent of W3C and ISO approval. Again, it's all to the good if W3C or ISO take up and promote commons-oriented standards.

Now, about "governed by a community of commoners"...

In the end, I believe that governance, whether formal or informal, is of vital concern to these processes. I imagine it is working well for you, with a small group of collaborators who are experienced, and have the appropriate skills and competence (or attitudes, values) to work together constructively. And it's great that there are significant things that can be done at this scale.

What happens, though, when either many more commoners have proper interests in interoperability? How can we avoid many small groups all coming up with their own solutions to similar problems? That's one of the places I think we need better coordination, and we need to think how.

You surmise that I have in mind "a new umbrella commons standards org". Well, the answer depends on what kind of org. I don't think that we need something that imitates W3C, ISO, etc. I would think that we need, perhaps not so much an organization as such, but a way of coordination that really works for the benefit of the commons. What kind of higher-level organizing do you think is needed?

I guess it's a bit like governance of more traditional commons. For small, local commons, maybe the informal face-to-face approach works. Great, if it does! But how are larger commons actually governed effectively (or, how could they be?) We have Ostrom and others to help us here, and we can apply her principles to our work.

Maybe we (those with an interest) could start exploring some examples of where harmonization / interoperability / standards have worked, or have not worked, to the benefit of the commons. We could agree that for some things, e.g. the IETF has worked well, and we would be best continuing. Maybe your current VF process is just fine as well. And we can start building the processes and coordinating structures that will allow us to tackle the larger-scale challenges.

What do you think?

We're going at this process pretty much bottom-up. VF is obviously insufficient. I expect the next stage will be federations of existing commons-oriented economic groups. This is happening now on a discussion level, and also in software collaboration. The software collaboration is actually economic work, but so far, I don't see it happening as a common economic network. Instead, each collaborating org sends a programmer or two to work on the software. Those people get together and tend to form their own small network as a project team, loosening (but not discarding) their identities as members of their "home" group. But their subsistence is either dependent on their home group or often a day job. So there is not a shared systematic economic context for the software work. Yet. It may come.

The groups will interact economically beyond the software project when they have some reason to do so. So far, not much happening there. I suspect it might happen first around food.

[edit] So I don't expect any larger standards org to be effective until several individual orgs are federated into an economic network. That network will require governance on the network level, and a larger standards org will evolve from it.

That's what I expect, but I could easily be wrong.

I mostly agree, and greatly appreciate the nuanced perspective.

I believe deeply in consent-based project management and community development which emphasizes personal autonomy and freedom of expression at each level of responsible participation. These principles prevent me from (literally) paying attention to most projects, including extractively managed walled gardens. These principles also limit the energy I give to projects which seem responsibly managed but structurally vulnerable to being destructively redirected without my consent.

Those concerns aren't very applicable to some standards networks which have clear pathways to open participation, and which I may interact increasingly with as time goes by. As work progresses, connections become clearer.

The groups will interact economically beyond the software project when they have some reason to do so.

I think this is a critical point. Enjoyable as it is to chew the fat with like minds, none of us have infinite time for talkshops. Work at the federation level only tends to persist where there is a critical mass of benefits for the groups federating.

The way the federated Indymedia network (Global Network of Independent Media Centres) fell apart is a classic example. After the initial wave of exponential growth and enthusiasm, some IMC groups either imploded, were excommunicated, or their key volunteers moved on to other projects. As more and more group exchanged dependence on globally shared infrastructure (webhosting, email lists, docs wiki) for more localized self-hosting, the benefits of federation were eroding, at the same time as the time and energy required of each group to sustain the network grew, creating a vicious cycle.

The economic benefits of federation can be non-monetary, but people can't sustain fulltime volunteer work for organisations that can't at least house and feed them (and in the case of tech work, supply computers and network connections). There were some tech cooperatives established at the time by Indymedia geeks, a few of which may still survive (would be fascinating to research). At the time I was a messianic champion of volunteerism, but in hindsight, Indymedia would have probably thrived, rather than becoming the zombie project it is now, if setting up workers cooperatives to pay geeks, researchers, and writers, had been core part of our network strategy. The emergence of groups like Loomio/ Enspiral, OpenCollectives, an the North American Technology Worker Cooperatives is a hopeful sign that the current generation of indymediatistas have learned from our mistakes ;)

To bring this back to the issue of standards harmonization, standards cannot and never are handed down from on-high, printed on stone tablets (or CD-ROMs). They emerge from the real needs and desires of real projects to achieve interoperation. IETF and W3C are examples of hubs where people try to achieve broad consensus, so they don't need to negotiate ad-hoc interoperation treaties with every other project (the ad-hoc approach obviously doesn't scale).

Those hubs are only dominated by corporations at present because the majority of the economic actors in the relevant fields are corporations, eg the makers of all the currently popular browsers (except Firefox). If and when that changes, eg more people start using free code browsers made by not-for-profits or platform cooperatives, then the way IETF or W3C processes work will change with it. Trying to change standards processes by changing the standards organisations, is like trying to make something that isn't mincemeat by putting the same meat into a different kind of mincer.

To reiterate the point I made on the other thread, that's not to say that standards work can only be done in the formal standards orgs. On the contrary, what passes through the IETF and W3C is usually just the final documentation and rubber stamping of tech that's either developed inside one company (eg Jabber > XMPP, or StatusNet > OStatus) or a more informal incubator like the WhatWG or ValueFlows.

what passes through the IETF and W3C is usually just the final documentation and rubber stamping of tech that's either developed inside one company (eg Jabber > XMPP, or StatusNet > OStatus) or a more informal incubator like the WhatWG or ValueFlows.

That's what we want to be when we grow up: an informal incubator!

@strypey thanks for that useful historical summary, I didn't know that. And I appreciate your perspective also, on both standards and group federation.

To bring this back to the issue of standards harmonization, standards cannot and never are handed down from on-high, printed on stone tablets (or CD-ROMs).

I love most of your last long comment, and I certainly agree with this declarative statement per se-- but, not with some potentially related assumptions.

Perhaps we can agree on this: standards can only emerge through inclusive dialogue?