Month: September 2010

“Open Source” is not a Verb; thoughts on Diaspora

Lots has been written about Diaspora already, so I’ll try to keep this as brief as possible. Reading the “overdue update” last month, I saw a phrase that made me a little crazy:

We have Diaspora working, we like it, and it will be open-sourced on September 15th.

Open source is not a verb in my book.

I thought of this again last night, while reading the excellent Security Lessons Learned from the Diaspora Launch. The errors described therein are truly horrifying, and I shudder to think how often I’ve made them myself. It was a comment in the final paragraph that really resonated for me, though.

You might believe in the powers of OSS to gather experts (or at least folks who have shipped a Rails app, like myself) to Diaspora’s banner and ferret out all the issues. You might also believe in magic code-fixing fairies. Personally, I’d be praying for the fairies because if Diaspora is dependent on the OSS community their users are screwed.

Diaspora isn’t screwed because the open source community is unreliable or unknowledgable. Diaspora is screwed because there isn’t just one open source community: communities develop around individual projects. And Diaspora blew the best chance they had to have an engaged, active community, today.

Diaspora did not “open-source” their software on the 15th. They licensed it. Perhaps I think about this pedantically due to six years working with public licenses, but I think it’s important to be clear about what change was actually affected: a licensing change. When we talk about open source software (or free software), we’re often talking as much about the environment that software grows up in as we are the license of the code. That environment includes the tools, the license (and/or contributor agreement, although why those are a bad idea is another topic altogether), and the community. Making choices for all three can be as important as any commit you make to your code base, and the three are often inter-related (for example, the choice of license may attract or repel individuals from a project, thus shaping community).

Of these three, I think community is the hardest to get right†. It’s also the hardest (in my experience) to make a course correction on, because you have less direct control. You get to choose your license; your community gets to choose you.

When Diaspora started raising funds on Kickstarter, the enthusiasm and engagement around the idea was incredible. And even if some of the conversation was at the technical level of unicorns and rainbows, I think people were ready to build something amazing. Unfortunately we were left in the dark all summer. How much different could it have been if the developers had opened a repository on gitorious, and started working in the open?

Would there have been security issues then? Sure. Would some people have criticized every little decision? Of course. But that’s sort of how these things work, and the effect is that this mass of people who have some interest in your project is refined to a community of users, testers, contributors, and fans. The people who care and agree with the direction your project is taking stay; those that don’t, leave (or fork). Additionally, you get to show people progress from day one, and avoid the whole “release” thing until you actually are ready (I think “releasing” raises expectations, even when you couch the version label in multiple levels of qualifiers).

So why don’t people do this? The times I’ve been tempted to do this, pride and ego have been huge parts of my motivation. We don’t want to show our early experiments because they’re “embarrassing”. Our use case is unique. We want to have something that meets some “minimum viable product” metric. We don’t want to disappoint.

When I start thinking this way, I need to get over myself.

Ben Collins-Sussman and Brian Fitzpatrick gave a great talk at OSCON 2009, “Programmer Insecurity and the Genius Myth”. And they quoted Tyler Durden.

“You are not a beautiful or unique snowflake. You’re the same decaying organic matter as everything else.

When discussing how to overcome the idea that your work is special, your use case is different, or that you’re “not ready”, one of the points they made is that it’s better to be a small fish in a big pond than a big fish in a small pond. That is, to get over your ego, get yourself a big fucking pond. Like a public repository that anyone can see.

So how does this relate to Diaspora and their lost community opportunity? I suspect at some point the folks at Diaspora decided, “we need to be ready before others see our code.” Or “we really need to focus on our work, so we can’t have that distraction.” So everyone who might have been inclined to watch commit messages, file bugs, or even contribute patches was left to think something along the lines of, “Man, who knows what they’re doing with all that cash; we’ll see what we actually get if and when they finally release.” (Remember, we all have Ego, and most of us are pretty attached to it.)

Now that they’ve made a release, and the results are not exactly what was hoped for, there are two things working against the nascent community: ego and inertia. Ego may be stronger, but don’t discount inertia: it’s a lot easier to correct your course when you’re moving slowly than it is when you’re hurtling towards a promised public launch. And asking a community to engage is a change in course, even when your code is perfect.

When Diaspora dropped their code on the 15th, they indicated that they want to orient towards a community.

Today, we are releasing the source code for Diaspora. This is now a community project and development is open to anyone with the technical expertise who shares the vision of a social network that puts users in control. From now on, we will be working closely with the community on improving and solidifying Diaspora.

It remains to be seen whether the community comes (and stays). Calling it a community project doesn’t make it so, but starting with community greatly increases the odds of successfully building one.

† Where “right” means something like “having an engaged group of users and developers that support and champion your project.”

date:2010-09-23 21:58:23
wordpress_id:1783
layout:post
slug:diaspora-community
comments:
category:open source
tags:community, diaspora, free software, open source

Book Report: “The No Asshole Rule”, by Robert Sutton

My annual review at Creative Commons took place at the end of July, and like last year, the emphasis was on the growing area of focus for me: management. I consider myself an accidental manager, but the anecdotal evidence is that I’m not terrible at it. The conversation during my review, and a prior conversation with a consultant from Teleos, led me to believe that I could improve my performance by learning more about “best practices” or “first principles”. So I’m trying to read some of the “literature”. While it’s not all directly applicable (or interesting), I think of it sort of like x86 assembler: I don’t want to write software in assembler, but I’m convinced that having some understanding of it helps me do better a better job at the work I do want to do.

The first book I chose to read was “The No Asshole Rule”, by Robert Sutton, a professor at Stanford University. Mike recommended Sutton generally, and this seemed like a good starting point. The entire book is an easy, enjoyable read, but there were a few pages I dog eared because they seemed particularly relevant or useful.

Sutton begins by defining an “asshole” as someone who meets two criteria: interactions with the subject leave you feeling oppressed, humiliated, de-energized, or belittled, and the subject specifically targets those less powerful than themselves. I think Sutton’s definition is useful because it distinguishes between people who are sharp-edged or anti-social, and those who leave others feeling like they’re less-than. I can’t think of a single job I’ve had that’s been completely asshole free by this definition, although the degree (and whether they’re colleagues, clients, or board members) has varied widely over the years. As my dad says, “you have all kinds of people, in all kinds of places.” All of that is to say that after reading The No Asshole Rule, I have a better idea what sort of people I want to minimize interaction with, and what sort of behavior I want to eliminate in myself†.

In his discussion on how to build an asshole-free workplace, Sutton describes the need to teach people how and when to fight: a team needs to be able to “disagree and then commit”. The second guessing, criticism of the decision, complaining, and arguing stops being productive as soon as a decision has been made. I have worked with people who, as soon as things are less than perfect, constantly remind others that they disagreed with a decision. In my experience, those reminders are demoralizing and saps energy from everyone around them (whether or not their co-workers or supervisors deign to respond).

Does this mean that you don’t evaluate whether a decision was correct so you can improve your decision making skills? Absolutely not. My interpretation is that to be successful (and avoid being an asshole), your decision needs to include what the definition of success is (metrics). That allows you to come back to the decision later and say, “You know, this decision was made assuming X, Y, and Z would happen; we see now X didn’t, so let’s remember that in mind next time.”

The No Asshole Rule doesn’t just talk about how to identify and protect against assholes; Sutton also discusses how to prevent your own inner asshole from getting out. One thing I found interesting was the discussion about how seeing your co-workers as competition is a sure fire way to ensure you’re an asshole. I know that I’m guilty of this. The joke, “It’s not enough to succeed, others must fail,” used to sound like a plausible approach to me. Sutton talks about why public shaming of under-performers is not useful, and how simple word choices (“mutual”, “share”, “fair”, vs. “enemy”, “battle”, “lawyer”) can help people cooperate better. When I worked at Canterbury, there were times I thought of meetings with the Technology Subcommittee of the Board as “battles” to be “survived”. While not without reason, this probably influenced the way I presented information and responded to questions. I’m sure it’s happened since then, too.

Sutton also includes suggestions on how to deal with assholes, if you’re not able to escape them. Two suggestions are looking for incremental wins, and not stooping to their level. The latter seems like a variation on my mother’s advice to “kill ‘em with kindness” and “turn the other cheek.” I still have a hard time with both, and my experience growing up was that neither is a guarantee that the asshole will stop asshole-ing.

Overall “The No Asshole Rule” helped me think about what kind of environment I want to be working in, what sort of people I like to work with, and how I can be a better co-worker and manager.

† As Sutton points out, most of us are assholes every now and then. Reading this helped me identify things I have done in the past and think about how I might approach the situation differently today.

date:2010-09-06 14:50:46
wordpress_id:1771
layout:post
slug:book-report-the-no-asshole-rule-by-robert-sutton
comments:
category:reading
tags:business, reading