Fuse: Connecting Your Car to the Rest of Your Life

I just backed my friend Phil Windley’s new Kickstarter project, Fuse. Everyone with a car should go back it now. Everyone who cares about data privacy should also go back it.

Every car has an on-board computer with tons of data: your mileage, your average speed, even your tire pressure. When you take your car into the shop, mechanics plug into this computer to access that data so that they can diagnose your car.

I’ve been wanting to access that data myself forever, and it’s not just because I’m a data geek. As someone who travels a lot for business, I track my mileage. Not only is it a royal pain to do manually, it just seems wrong, given that your car already has this data. But until recently, I had no ability to access it.

Fuse unlocks that data, and gives you access. It consists of a device that you plug into your car’s diagnostic outlet and a mobile app that gives you access to that data.

That alone should make you want this. But I’m going out of my way to blog about this project because of what Fuse does under the hood.

The problem with most of the emerging apps in this space is that they essentially trade convenience and coolness for ownership of your data. Most of us don’t pay attention to that. We’re too pre-occupied by the coolness. Some of us feel vaguely uneasy about the trade-off, but we do it anyway. Coolness is a powerful motivator.

Phil has been a leader in the digital identity space for a very long time. He literally wrote the book on it. He’s part of a community of folks who thinks that you — the individual — should own and control your data. Enabling this is a hard technical problem, but it’s an even knottier social problem.

Fuse is built on top of a trust and privacy framework that my friends, Drummond Reed and Andy Dale, have helped evolved. Fuse is cool, compelling, and socially responsible. These are the kinds of apps that will help create the kind of world that I want to live in.

If you’d like to read more about these nitty gritty aspects of Fuse, go check out Phil’s blog. If you’d like to read more about the bigger vision behind technology like this, start with Vendor Relationship Management (VRM).

Don’t forget to back the project!

What My Reading List Says About Me

I’ve written before about Terrell Russell’s notion of contextual authority tagging. Drummond Reed is playing with these ideas with his new startup, connect.me, and LinkedIn recently started doing something similar with its endorsements.

I’ve performed my own mini-experiment to see what would happen if I asked others to describe me, which was self-indulgent but also interesting. On the other hand, I’ve been a bit disappointed by my LinkedIn endorsements, because I don’t feel like they represent me well.

I’m a hard one to nail down. I have lots of different interests, and while they’re all form an integrated whole in my head, that may not be as apparent to others. It got me thinking about whether or not I pay enough attention to my online persona. The answer is probably not, but the real question is whether or not I care enough to do something about it. (Again, the answer is probably not.)

So then I thought about looking at other data about myself to see what I could learn. I decided to check my Evernote tags. I’ve been an avid Evernote user for several years now, and it is my primary tool for clipping interesting articles. I’m also an avid tagger, so I have a pretty good emergent taxonomy to use for analysis.

I decided to look at my most frequent, topical tags. (I have a set of tags that I use for internal organization, which are irrelevant for the purposes of this analysis.) I then created a tag cloud using Wordle. Here were the results:

Evernote Tag Cloud (2012-10-20)

It’s fairly representative of the things that I’m interested in. If I were more consistent about tagging, the “sports” tag would be larger. (I have several articles tagged by specific sports, such as “basketball,” as opposed to the more generic, “sports.”) Same with “entrepreneurship.” (I have a bunch of articles tagged “startup.”) A lot of the “psychology” articles are actually about behavior change.

What do you think? Would you have guessed these about me? Are there any tags that surprise you?

Identity Commons Sessions Summary (June 21, 2006)

There were two sessions on Identity Commons on the Open Space day (June 21, 2006) at the Identity Mashup at the MIT Media Lab last week. The first session was an open status meeting for the community at large. We described Identity Commons‘s purpose, told the history of the organization, then explained how the organization could serve the community today and why the existing organizational structure wasn’t adequate. We then announced that the current trustees had authorized a brand transfer, assuming that the new organization adopted purposes and principles consistent with the current purposes and principles.    (KQL)

Both sessions were well-attended, and there were a number of new faces. Interest in participation seemed strong.    (KQM)

In brief:    (KQN)

  • There are a number of grassroots community projects that involve multiple stakeholders and that are happening independently of any centralized direction.    (KQO)
  • These decentralized efforts could all benefit from some shared infrastructure, which could be as simple as a shared, neutral brand (i.e. “Identity Commons“) or as complicated as a set of rules that help ensure fair participation and governance among multiple parties.    (KQP)
  • Our strategy is to build an organization organically that addresses the needs of these different community projects.    (KQQ)

Current projects/interests (and stewards) include:    (KQR)

These projects could benefit from things like:    (KR1)

  • Shared name. The importance of this can’t be understated. It demonstrates solidarity, implicit community cooperation, which is particularly important for this community. There’s also an implicit reputation (hopefully positive) associated with a shared name that encourages participation in the community.    (KR2)
  • Bank account. Several of these projects need a bank account. A great example of this are the various community gatherings, which need the ability to accept registrations and spend money on things like space rental and food.    (KR3)
  • Online community space. Many of these groups are already using mailing lists and Wikis for discussion and group authoring. It would simplify things for new groups if these resources were easily available to those who wanted them. It would also benefit the community at large if some of these groups had their discussions on a shared space as opposed to separate silos.    (KR4)
  • Governance and process. Some fundamental guidelines can help all groups facilitate cooperation and participation from all stakeholders.    (KR5)

Eventually, what we’re currently calling “Identity Commons 2.0” will need:    (KR6)

  • legal entity w/ bylaws and membership criteria    (KR7)
  • financial model    (KR8)
  • intellectual property agreement (potentially using Apache Software Foundation as a model)    (KR9)

Our strategy for addressing these needs is to attack the low-hanging fruit first and to let the projects drive the priorities of the organization. We will start by forming an organizational working group consisting of the stewards of each of the working groups described above as well as anyone else from the community who wants to join. Its first meeting is a teleconference tentatively scheduled for next Thursday, July 6 at 9am PT, pending confirmation from the different stewards. (Details to be announced on the community mailing list.)    (KRA)

Organizational policy should be as lightweight as possible, giving each working group the option of customizing them to fit their needs.    (KRB)

We will use the community mailing list for discussion. We will also setup a Wiki, leveraging the work Jon Ramer did for Identity Mashup. We will look into merging some of the other Wikis, such as Identity Gang, into this new Wiki.    (KRC)

Who will decide what working groups form or what collaborative tools we’ll use? In general, if someone wants to propose something that’s consistent with the purposes and principles, the answer is “yes” — provided someone is going to steward the proposal.    (KRD)

Developing Shared Language

Drummond Reed recently wrote about the Identity Rights Agreements session at last month’s Internet Identity Workshop. While the outcome was fruitful, Drummond wrote, “The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject.”    (KNJ)

Jamie Dinkelacker told me a similar story last year in describing a SOA gathering of gurus. The goal was to share knowledge and to advance the state of the art, but the participants spent most of their time arguing over the definition of “services.”    (KNK)

The problem in the first case was with expectations. The participants should have expected some ramp-up time would be necessary to get started, because they needed to establish some Shared Language. The problem in the second case was with process. The participants did not have an effective strategy for developing Shared Language, and thus, the latter ended up monopolizing the whole workshop.    (KNL)

Shared Language is a prerequisite to collaboration. Without Shared Language, we can’t collaborate. It’s as simple as that. When a group tries to collaborate without having Shared Language, the group will try to create it, whether it’s aware of it or not. This creation process is often frustrating and painful, and as a result, people sometimes try to skip this step or belittle the process. This is a problem. You can’t skip this step.    (KNM)

When designing collaborative spaces — both online and face-to-face — you have to build in time and space for developing Shared Language.    (KNN)

If you examine every good collaborative, face-to-face process for large groups, you will find that all of them generally recommend a minimum of three days. I haven’t found a rigorous explanation for why three days work so well, but the pattern is consistent, and we can certainly speculate. Much of it has to do with building in enough time to develop Shared Language. (Michael Herman, Open Space facilitator extraordinaire, has suggested that it’s less about the three days and more about the two nights — having our minds go through two natural work-process-rest cycles. I think he’s onto something.)    (KNO)

The first day is always about developing Shared Language. MGTaylor calls it the “Scan” day. Phil Windley calls it the “butt-sniffing” day. Regardless of what you call it, you need to design for it. It’s going to happen whether you like it or not. The question is whether or not it will happen effectively while leaving time for action.    (KNP)

There are two myths regarding how you create Shared Language. The first is that “shared” is equivalent to “same.” They’re not. Shared Language means that you understand how others around you are using terminology. Some level of sameness is obviously useful, but when you’re dealing with something relatively complex, sameness is both impossible and undesirable.    (KNQ)

I devised a metric several years ago called the Squirm Test that’s similar in concept to Wikipedia‘s Neutral Point Of View. The test is simple. Sit your team around the table. Have each person stand up and give a brief project description and status report. During the pitch, no one is allowed to talk, other than to ask clarifying questions. You have a perfect level of Shared Understanding and Shared Language if you make it around the room without anyone squirming.    (KNR)

The second myth is that creating Shared Language consists of creating a dictionary. That’s certainly one way to approach it, but it’s not the only way, and often times, it’s not the best nor the fastest way.    (KNS)

There are three elements to creating Shared Language:    (KNT)

  • Share individual contexts    (KNU)
  • Encourage namespace clash    (KNV)
  • Leave enough time and space to work things out    (KNW)

Sharing individual contexts is a fancy way of saying, “Know your audience.” Or, more accurately, know who you’re working with — their world view, their values, etc. You don’t have to use the same terminology the same way; you just have to understand what people mean and where they’re coming from. For some techniques on how to do this, see Collab:KnowTheParticipants.    (KNX)

I’ve written many times about how Wikis and tagging encourage namespace clash, which in turn encourages Shared Language. From a facilitation standpoint (both face-to-face and online), if you pose questions that stretch the mind, you also draw out namespace clash. MGTaylor is especially good at doing this with its Design Shops. Allen Gunn uses a technique called a spectrogram where you stretch a piece of masking tape across the room, ask a controversial question, then tell people to go to the place on the tape that represents their position on the question. You then ask people along the spectrum why they’re standing where they’re standing, and you give people the chance to move around based on other people’s answers. If you ask the right question, you’ll not only quickly get a great sense of your audience, but you’ll also draw out different interpretations of language.    (KNY)

Finally, simply scheduling time and space where Shared Language is the primary goal is useful. People are good at figuring out how to communicate with each other if you give them the space to do it. If you set unrealistic expectations on the first day of a three day event, then you just stress out your participants. If you spend the first day exploring broader questions, your participants may feel flustered or frustrated, but they will find that the work goes much more smoothly in the ensuing days.    (KNZ)

Developing Shared Language is an ongoing process. Doing actual work is one of the best ways to build shared context, which in turn builds Shared Language. The trick is to have stagger your work goals based on the Shared Language that already exists. The exercises you go through can become more and more focused over time, as the amount of Shared Language increases.    (KO0)

At the Blue Oxen Associates Tools for Catalyzing Collaboration workshops — one-day workshops with about 25 participants — we don’t do participant introductions. We assign teams and have people go straight into their exercises. However, we pay careful attention to how we assign the initial teams, and we structure the exercises accordingly. For example, at our January workshop, we started by pairing people who either already knew each other or were in similar fields, and we had them start their exercises immediately. We then grouped pairs and had them present their work to each other. Finally, we had a plenary session where each group reported on their work, followed by a plenary discussion. Our participants were engaged right away, and the shared experiences acted as an icebreaker, which made it easier to meet new people and to talk in our designated networking times (e.g. lunch). We also had online profiles up on our Wiki, so that people could find out more about the other participants before, during, and after the workshop. Several people commented afterwards about the lack of group introductions. All of them liked it.    (KO1)