eekim.com: EEK Speaks

Wed, Nov 28, 2007

barx: A Ruby XRI Resolver #

Last month, VictorGrey and KermitSnelson announced barx, the first full implementation of the XRI 2.0 draft specification (working draft 11, for those of you keeping track). I finally downloaded and started playing with it tonight; it's very nice. Most OpenID implementations are using a proxy hack to support i-names, but as real XRI implementations start to come out, we'll start seeing many more interesting applications. (MS5)

I've started to port barx over to Perl and will hopefully have it completed by IIW next week. Yes, I'm coding again. I've been sitting on a slew of year-old ideas that need to get implemented, and I'm tired of being a preacher instead of a do-er (at least when it comes to code). It's against my instincts, and I don't have enough of an audience to leverage the LazyWeb. (MS6)

Besides, I was starting to miss it. Over the last few years, I've built a reputation as someone who knows a bit about collaboration, not just about tools, and that's been really gratifying. It's also helped me feel okay about reminding people that I still know a bit about tools as well. Plus, a lot of things have been stoking the fire recently. I was managing the HyperScope project last year and the GrantsFire project this year, both of which are conceptually and technically interesting. I never stopped reading code, and a lot of my friends are developers. What really kicked things into gear for me, though, was stepping in as an emergency developer for GrantsFire and watching LinusTorvalds's git talk. (MS7)

I started playing with a bunch of ideas at once, but I'm focusing on GrantsFire and the DigitalIdentity stuff now. Stay tuned, and if you want to hack with me over the next few weeks, either face-to-face or remotely, ping me. (MS8)

/collaboration/idcommons | Posted at 2:51am

Mon, Jun 18, 2007

The Case for Distributed Social Networks #

(MCA)

Courtesy of bLaugh. Spotted by Barnraiser. (MCB)

/collaboration/idcommons | Posted at 12:49am

Sat, Apr 07, 2007

Voting, Collective Leadership, and Identity Commons #

Thanks to next week's Creating Space, CollectiveLeadership has been on my mind a lot recently. It's also been a key element of the new IdentityCommons. One of the issues we've been grappling with is decision-making. To understand why this is a challenge, you have to understand the underlying structure and philosophy of the organization. (M5R)

Ultimately, IdentityCommons is a CommunityMark that represents a set of values concerning DigitalIdentity. It's a name bestowed on the community of folks who care about UserCentricIdentity. If you care about this stuff, then you are part of IdentityCommons. There is nothing to join, and you are free to use the name and logo as a way of demonstrating your support of these values. (M5S)

Why this is such a powerful and important construct is a topic for another day. What's interesting about this particular community is that there's also a corresponding legal structure, a nonprofit organization that is in the process of being incorporated. This organization consists of community "Stewards" -- people appointed by the community to represent the interests of particular sub-communities ("Working Groups") and who are responsible for managing the tangible assets of the commons. There are rules for becoming Working Groups and Stewards, but they are extremely lightweight. (M5T)

All of the Stewards comprise a Stewards Council. Each Steward has an equal vote on all matters. There is a Chair, but that position is mostly facilitative. There is also a Chief Catalyst, someone (not necessarily a Steward) who is responsible for handling the operational duties of the organization and catalyzing action in the community. (M5U)

It's a fascinating, but delicate structure. The Stewards Council has an important leadership responsibility, but that role is distributed equally among all of the Stewards. How do Stewards exercise leadership effectively given this structure? Decision-making via voting is clumsy in many contexts, and yet that's the only process that we've actually defined. (M5V)

We've had a number of interesting conversations on the topic, and the latest discussion recently surfaced a lurker, MartienVanSteenbergen, who cited an interesting reference on holacracy. Martien quotes the following excerpt (emphasis his): (M5W)

Another common question is about the "possible votes" in integrative decision making. At first it can sound like there are two possible votes on a proposed decision -- "consent" or "object" -- though that's missing a key point. Consent isn't about "votes" at all; the idea of a vote doesn't make sense in the context of consent. There are no votes, and people do not vote. (M5X)

People do say whether they know of a reason why the proposed decision is outside the limits of tolerance of any aspect of the system, and then decision making continues to integrate that new information. This isn't the same as most consensus-based processes -- either in theory or in practice -- although it does sound similar at first, especially before an actual meeting that seeks consent is witnessed. (M5Y)

This quote is keying on the difference between CollectiveLeadership and consensus leadership. They are not the same thing. With CollectiveLeadership, you are acknowledging the multi-faceted requirements of leadership, and you are empowering those best suited to meet those requirements to fulfill that leadership role. You are not voting on every decision, which would be a sure path to disaster. (M5Z)

One of the ways this manifests itself is by making decisions "without objection." This is a technique from RobertsRulesOfOrder that JoaquinMiller brought to our attention. Essentially, you empower people to act, unless someone in the group objects, at which point an alternative process kicks in. Everyone still has a voice in the decisions, but it is a proactive rather than a reactive style, and it encourages action rather than stagnation. (M60)

I believe that when you have great collaborative process, voting is a rubber stamping process, even when the topic is controversial. In other words, the actual decision-making process starts well before any vote happens. Healthy deliberation results in SharedUnderstanding, which in turn helps to surface clear courses of action that navigate through the obstacles of contradictory ideologies. When there is pressure for movement (another pattern of high-performance collaboration), then people will rally around those courses of action. (M61)

/collaboration/idcommons | Posted at 9:46am

Wed, Mar 07, 2007

Terrell Russell on STODID #

Last week, I wrote glowingly of TerrellRussell's work on ContextualAuthorityTagging. You can hear the man himself talk more about it on AldoCastaneda's latest STODID podcast (The Story of Digital Identity). (LYY)

At first, I was a bit surprised that they didn't talk much about ClaimID, which is Terrell's other cool project related to DigitalIdentity. I then realized that Aldo had already interviewed FredStutzman about ClaimID last year. On this week's podcast, Terrell alluded to his various projects converging. Poking around ClaimID today, I could see where ContextualAuthorityTagging could possibly rear its head. Exciting stuff. (LYZ)

/collaboration/idcommons | Posted at 12:36pm

Tue, Nov 21, 2006

Implications of the Kintera Data Sharing Announcement #

AndyDale reported earlier this month that La Leche League will be using Kintera's software for member and donor management. More importantly, the two organizations will use open "standards" to share data between their respective systems. Andy's company, ooTao, is implementing the data sharing using technology known as XDI. (LK3)

The data sharing problem is well-known in every large organization, and it boils down to this: You have common data across multiple systems and databases, and none of it is linked. Because it's not linked, it's difficult to update information, it's difficult to maintain a high-level accuracy, and it's difficult to do any serious reporting. Every time you add a new system, it gets exponentially harder to do all of the above. (LK4)

Does Kintera's announcement mean that the data sharing problem has been solved? No. But it's still an important announcement. To understand why, it's important to delve a bit deeper into what makes the data sharing problem hard in the first place. (LK5)

First, standards are inherently hard. (LK6)

Second, getting an established market of vendors to agree on a set of standards is even harder. The problem is that every vendor thinks that lock-in is good for their business. The bigger problem is that they're absolutely right, as long as lock-in is the status quo. Open data sharing is not viable until a critical mass of tools support it, and there's no short-term return on being first to market (other than marketing value, which I would argue is underappreciated). (LK7)

Third, those who have been trying to address the problem have been going about it the wrong way. In particular, they've made the social problem bigger when it should be smaller, and they've made the technical problem smaller when it should be bigger. (LK8)

The most common mistake that people make when trying to agree on a standard is to try to get everyone on board up-front. That is the path to certain failure. The best approach is to get two people on board up-front, build something that works and is open, and then approach others about joining the effort. Getting small groups of people to collaborate is hard enough. Don't make it harder than it needs to be. (LK9)

On the technical front, people seem to have oversimplified the problem. It's not just about coming up with the right set of APIs and XML schemas. You have to also think about identity -- on many levels, as it turns out. The data needs to be addressable, which means you have to think deeply about identifiers. Also, the most common type of common data is people information -- in other words, digital identities. The requirements around DigitalIdentity -- especially UserCentricIdentity -- are more complex. The good news is that engineers are well-equipped to handle this kind of complexity; you just need to make sure it's part of the problem statement. (LKA)

Back to the Kintera announcement. They're doing the right thing by building something that works between two organizations, rather than declaring a standard up-front and trying to convince everyone to jump on board willy nilly. (LKB)

They're also doing the right thing by hiring ooTao to implement this piece, because ooTao understands the identity problem, and it has credibility in the grassroots identity community. While calling XDI a "standard" is a stretch -- there's not even a published spec yet -- it will most certainly be open, and a number of organizations and individuals have already contributed to it. More importantly, all of this stuff will work with OpenID and i-names, two technologies that can be accurately called open standards. (LKC)

Will XDI "win"? It doesn't matter. The architectural and practical lessons learned in implementing and deploying something real will move us one significant step closer to solving the data sharing problem, regardless of the role that XDI plays in the the long-term solution. (LKD)

Should you avoid XDI because of the uncertainty over whether it will "win"? Absolutely not. The architectural changes you will need to make to support XDI will be largely spec-independent. Should you need to migrate to a different spec at a later point, the work required will be relatively minor. (LKE)

/collaboration/idcommons | Posted at 7:59am

Tue, Oct 24, 2006