Open Collaboration. An outline.

Open code increases collaboration because…

• it allows for peer review and and shared construction of knowledge. The code-base is the collaborative medium. Staff can grow, try things out, challenge themselves and their colleagues.
• it allows industries to improve and build on what has gone before
• It allows parts to be shared, not just wholes

Open source development increases collaboration because…

• It provides a structure to come together around the design and development of a shared product
• It engages the users in the evolution of that product
• The conversations are not just about implementation within the constraints of the product, but about what could be

Open content increases collaboration because…

• It allows for the shared construction of knowledge through access, reuse, and extended contexts
• Nobody is on the outside (banging on the door or being left in the dark)
• The content provides a platform for people to engage about ideas
• It reaches out beyond the confines of a given group and opens us to the serendipitous engagement and discovery of the internet

Collaboration opportunities change when faced with an open environment because people think differently about the problem if they can directly impact it through their own contributions.

“Just the Way I Roll”

Recently, when I asked my son (politely) whether he planned on taking his clean clothes out of the hamper and putting them away or leaving them there as his new dresser, he answered, “that’s just the way I roll these days.”

I have found myself silently inserting this answer in response to many situations since then. I wouldn’t say it is a phrase that comes close to characterizing my modus operandi, so I have to say it feels quite deviant and satisfying to adopt as a pseudo cynical yet self-affirming mantra. You can see (am I stretching it here?) how it might lend itself to the philosophy espoused in Gallup Inc., build on your strengths. For anyone who is high in the Executing domain, this should come as a welcome release. Perhaps Gallup should change their title, to “Which Way do You Roll?” in order to attact some of my son’s hipster friends (OK, he says they aren’t hipsters, but what do I know?).

Managing Input in Community Source UX Design

Managing input to design in the large distributed community and open source projects can be challenging. Transparency is good. We all agree. However, when does transparency become a hindrance? When is it critical to success? Understanding and defining these lines is incredibly important but also very very hard. It is especially challenging when everyone and their sister (that would be me) has an opinion, is an armchair designer, a user of some sort, and wants to help. Tonight, over dinner with several of the Fluid Project designers and Clayton Lewis, professor of computer science at Colorado University and collaborator in the Fluid project (among many other things), we discussed such issues.

One issue that I have been noodling on is that in community source we use email to share ideas. Text. Explaining what are inherently visual and dynamic ideas via text sucks. Our language should should not be text first. The posed answer may be (and it was), “but I can write something in 15 minutes what it would take me an hour to draw.” Yes. But, if you take all the interpretation time and questions and back and forth time required for each person to visualize and explore and conclude… perhaps the entire cost to the effort is much higher in text at the end of the day. Clayton pointed out that there are some interaction/UI issues that can never be worked out until you start to mock-up the interaction — solve those problems earlier and get the visual in front of real users (not me in most cases) earlier.

It is true that once it is in a visual format, it is harder to go back. But, it is a lot easier (and cheaper) than when it is coded, QA’d and released…

I remember when I used to do graphic design and art (the good ol’ days). There was always that moment of truth when you had to let someone else see it. When you had to explain it and justify it. That is a difficult moment. It feels very exposed. Very risky.

So, if we go back to that transparency issue, that is transparency as a Value (capital V), designers are always taking risks. Perhaps we can license them to do this. Provide a free pass and find a way to liberate us from the burden of text so we can get to the truth of what works and doesn’t work for the user much more quickly and keep those of us armchair “opinionaters” at bay because we just love anything that glitters.

Sometimes silence is golden.

Dinner was good. Thanks Clayton, Allison, Rachel, Daphne, and Oliver!

Email is a chatty medium, it is hard to visualize an interaction

Sakai Amsterdam Conference — Planning and Coordination

I am here at the Sakai Conference in Amsterdam. Well, really the conference hasn’t officially started yet, but there have been planning and coordination meetings for the past two days. The planning meeting was well attended by a diverse group of institutions and roles. One of the hot agenda items was about technical governance. At least it started there and went on to reveal many different perspectives and issues about overall product governance needs. Needless to say that after a couple of hours (was it that long?) of wandering about and exposing different parts of the elephant, we delegated the conversation to a bunch of volunteers to discuss today (Sunday).

The second part of that discussion today was much more manageable (one topic to discuss, fewer people), but we continued to grapple (and circle) with what the real problem was, and how far down the solution road we (as a group of 15 or so) should really go. At the end there are a few people who will be creating proposals to bring back to the community.

This was a lot of work. It was a lot of money for those involved. Will it make for a better release? Will it result in tangible results with concrete impact. I am skeptical — At least for today, tomorrow, who knows? At the very least I think the time and discussion has served to build some bridges and what I think is a shared set of high level principles (even though they haven’t really been articulated or documented).

I came up with a rough sketch of something that is probably too structured to begin with and reveals my biases toward some accountable organizational bodies, but at least it may give people something to poke at.