Tag Archives: mozilla

more on segmenting open source communities

Leave a reply

I wanted to following up on yesterday’s post about the topology and segmentation of open source communities  with one or two addition comments.

My friend Rahul R. reminded me of the fact that one critical reason we segment is to more effectively allocate time and resources. In a bell shaped vision of the open source community (to get this you really have to read yesterday’s post) it would make sense to allocate the bulk of time on the centre (or average) user. But in a power law distribution, with a massive majority of community participants poorly networked to the project a community may face an important dilemma. Consolidate and focus on current community members, or invest in enabling a group so massive it may seem impossible to have an impact.

But as I reflect on it, this segmentation may create a false choice.

Concentrating on the more connected and active members may not be beneficial. A community needs to cultivate a pipeline of future users. Focusing on current community leaders at the expense of future community leaders will damage the project’s long term viability. More importantly, as discussed yesterday, consolidating and insulating this group may acutally create barriers to entry for new community members by saturating the current key members relationship capacity.

The reverse however, concentrating on a mass of passive users, trying to transform them into more active community members is a daunting task (especially when you are considering a user base of 20-30 million, or even just a beta tester community of 100,000 people). While I think there are a number of exciting things that one can and should do to tackle this segment, it can, and does feel overwhelming. How can you have impact?

The key may be to leverage the super users (or super-nodes – those who are more likely to be connected to people throughout the community) to create a culture that is more inclusive and participatory. Over the long term, successful open source communities will be those capable of not only drawing in new members, but networking them with key operators, decision makers and influencers so that new branches of the community are seeded.

I suspect this does not necessarily occur on to its own. It requires an explicit strategy, supported by training, all of which must be aligned with the community’s values. This will be especially true as newer entrants will have a diverse background (and set of goals and values) then the original community members. Possibly the most effective way to achieve this is to inoculate the super nodes within the community with a degree of openness to diversity, and a capacity for relationship cultivation and management so as to create an open culture that functions well even with a diverse community.

So let’s segment the community- but let’s also use that segmentation to build skills, awareness, etc… in each segment that allows it to contribute to a strategy that transcends each individual segment. For an open source community, I would suggest that, at a minimum, this means offering some training around relationship management, dispute resolution, facilitation and mediation to its super-nodes – e.g. the people most directly shaping the community’s culture.

Messina and Firefox

6 Replies

So I know I’m late to the party but wanted to contribute some thoughts to the Messina debate on Mozilla.

What I find most interesting are not the specifics of the discussion, but the principles beings discussed and the manner by which they are being discussed.

Break Messina piece down and he is essentially making two assertions:

1. “I don’t understand Mozilla’s strategy” and (unsurprisingly!) here are my ideas
2. “Let the community rule”

The response, has been fairly quiet. Some were clearly frustrated. Others saw it as an opportunity to raise their own pet issues. What I haven’t seen (on Planet Mozilla) is a post that really engages Chris’ ideas and says “I don’t agree with Chris on ‘a’ or ‘b’, but he’s right about ‘c.’ ” To be fair, it’s hard to react well to criticism – especially from someone you count on as an ally. When you spend your day fighting billion dollar beasts you don’t exactly want to spend time and energy defending your rear.

However, the silence risks increasing the gap between Mozilla and those who agree with Chris (which judging from his blog may or may not be a fair number of people). I was struck that one commentator said: “I didn’t know somebody could talk like this about Firefox until now.” Such a comment should be a red flag. If the community has some sacred cows or self-censors itself, that’s a bad sign. For this, and other reasons, the thrust of Messina-like rant’s may have significant implications for the future of Mozilla.

The problem is that as the Mozilla community grows and the choices for where to concentrate resources become less and less ‘obvious,’ the community members will increasingly want be part of the strategic decision-making process. When the objective is clear – build a better open browser – its easy to allocate my scarce economic resources towards the project because the aim is obvious (so I either buy-in or I don’t). But as success takes on more nebulous meaning, I need to understand why I should allocate my time and energy. Indeed, I’m more likely to do so if a) I understand the goal and b) I know I can help contribute to deciding what the goal should be.

In this regard Mozilla need to constantly re-examine how it manages strategy and engages with its community (which I know it does!). Personally, I agree with Messina that Mozilla is not a browser company. Indeed, in a previous (not entirely well formed) post, I argue that Mozilla’s isn’t even a software company. Mozilla’s is a community management organization. Consequently its core competency is not coding, but community management. The concern (I think) I share with Messina (if I read between the lines of his rant) is that as Mozilla grows and becomes more successful the decisions it must make also become increasingly complex and involve higher stakes. The fear is that Mozilla will react by adopting more corporate decision-making processes because a) its familiar – everybody knows how this process works and b) its easy – one can consult, but ultimately decisions reside with a few people who trust (or at least employ) one another.

However, if Mozilla is a community management organization then the opposite is true. Mozilla needs a way to treat its strategy like its code, open to editing and contribution. I know it already strives to do this. But what does open-strategy vs. 2.0 look like? What does community management 2.0 look like? Can Mozilla make its community integral to its strategy development? I believe that at its core, Mozilla’s success will depend on its capacity to facilitate these discussions (I may even use the dreaded term… dialogues). This may feel time consuming and onerous, but it pales in comparison to the cost of losing community members (or not attracting them in the first place).

If Mozilla can crack this problem then rants like Messina’s won’t be a threat, they’ll be an opportunity. Or at least he’ll a place where he can channel them.

The Smyth Deal: The Anatomy of a Positional Negotiation Gone Wrong

9 Replies

A classic negotiation challenge is when parties lock into positions. Both sides articulate a demand – usually followed a threat such as “take it or leave it” – and then hopes the other side blinks first.

In the case of Ryan Smyth and the Edmonton Oilers’ I can almost imagine each parties’ statement. Smyth’s agent probably declared “my player is worth $6M dollars not a penny less – take it or leave it.” While the Oiler representative said “we can afford $5M and not a penny more – otherwise, we’ll go to the trading block.” Then, with both sides locked into a price, two things probably happened. First, the negotiation was restricted to a discussion about money to the detriment of the parties numerous other interests. Second, any change in either parties’ position would cause them to lose credibility and/or face. Consequently, any progress in the negotiation would have paradoxically increased the level distrust by confirming each party’s suspicion that the other could and would bend more.

And of course, this is what happened. Smyth was willing to accept less, and the Oiler’s were willing to pay more. A fact made evident as they managed to haggle their way to a difference of $5.4M and $5.5M per year. But getting closer probably had the perverse effect of making the negotiation harder. Each concession made the subsequent ‘demands’ appear less credible and firm. So, to prove that this was indeed ‘their final offer’ each side had to appear more and more inflexible. The result? A negotiation that collapses over a disagreement of $100,000 a year or $500,000 over the life of the contract – about 1.8% of the deals’ monetary value. Oiler’s GM Ken Lowe’s statement this was “a hockey decision and not a financial decision’ is laughable. This was neither a hockey or a financial decision – it was en ego decision.

Indeed, a tearful Smyth was more honest. While getting on a plane at Edmonton International Airport he summed up the process by virtually pulling the definition of positional negotiation out of a textbook: “We were stuck in our concrete, they were stuck in theirs.” (Edmonton Journal) Interestingly, the very fact that Smyth was crying indicates that, while both parties were arguing over money, financial concerns probably only made up a small fraction of each party’s numerous and complex interests.

To contrast against their positions I’ve quickly brainstormed the following list of each party’s core interests:

 

Ryan Smyth’s Interests

 

Oiler’s Interests
  • Maximize (or receive fair?) compensation
  • Set precedent for future negotiations
  • Stay close to/not have to relocate, family
  • Maintain links to community
  • Play on winning team
  • Play on Stanley Cup contender
  • Profitable franchise
  • Increase franchise’s marketability
  • Increase personal marketability
  • Increase interest in hockey
  • Play in a market where hockey is a major sport
  • Minimize (or pay fair?) compensation
  • Set precedent for future negotiations
  • Profitable franchise
  • Field a winning team under the salary cap
  • Field a Stanley Cup contender
  • Increase franchise’s marketability
  • Increase Smyth’s personal marketability
  • Increase interest in hockey
  • Maintain/improve morale of team and fans
  • Strong positive presence in the community

As you can see, money makes up only one (albeit important) piece of the puzzle. But in both cases numerous other issues whose value cannot be easily quantified also factor importantly.

For example, one wonders if $100,000 a year (our of $5.4M!) was worth forgoing if it allowed Smyth’s to keep his family in Alberta and stay close to them (especially given the after tax value of the $100K). Smyth probably also had an interest in maintaining/continuing his community work in Edmonton, a place he likely genuinely considers home (unlike Long Island). Smyth probably also had an interest in ensuring that the Oilers have enough money under the cap to acquire other key players that would have given him the chance to hold up a Stanley Cup.

Meanwhile, the Oiler management likely have an interest in players that are marketable and increase the profile of the team in the community (which Smyth is uniquely positioned to do). One wonders how much the lost revenue from merchandising will cost the Oilers. In a small market a local town hero can be worth their weigh in gold (and then some).

The point is that Smyth and the Oiler’s had relatively few conflicting interests compared to those that were either common or simply different (but not conflicting). Had both parties looked at their full range of interests, and not focused almost exclusively on money, it’s hard to imagine that some creative value-increasing options were not possible. For example: the difference of $100,000 could have been donated to a charity of Smyth choice every year – thus helping Smyth’s marketability, improving both his and the Oiler’s standing in the community all while not contributing to the salary cap. Or the $100,000 could have been converted into bonus pay contingent on Smyth’s performance. Ultimately, two negotiators thinking creatively about this negotiation as a collective challenge, and not locked into an ego-driven game of chicken, could have found a deal. But then Smyth’s agent is probably rewarded based on the money he pulls down and the Oiler’s manager on how much money he saves, so in the end money drove the negotiations… right over the cliff.

[tags]NHL, negotitation, negotiating, Ryan Smyth, Oilers, Edmonton, mozilla, sports, hockey [/tags]

Community Management as Open Source's Core Competency

11 Replies

Reaction to this post has been overwhelming – I made it the basis of a presentation at the 2007 Free Software and  Open Source Symposium at Seneca college. You can watch it here as a slidecast.

A good friend of mine, Mike B. and I have been exchanging thoughts on open source projects. Mike’s experience is grounded in the ‘traditional’ world of open source – he works on the web browser Firefox (which if you don’t use, you should). I freely admit my own open source credentials are more suspect – I draw my lessons from my experience engaging in a form of open source public policy through Canada25. Beyond, that, what I know is based on what others are kind enough to share with me, and what I am able to learn through articles, books and podcasts.

For those not interested in the whole spiel below the short version is this:

Companies or foundations that run open source project are not software firms, they are community management firms whose communities happen to make software. Consequently to survive and thrive these projects need to invest less in enhancing governance structures or employees who/that will improve their capacity to code. Instead, we should consider skills and structures that emphasize facilitation, mediation, and conflict management – tools, skills and structures that will enable the community to better collaborate.

More detailed thoughts I’m fleshing out an idea flow that goes something like this:

  1. Open source software firms (like Mozilla, the makers of Firefox) are not software companies, they are community management firms whose community happens to produce a software package. (I’ll talk more about Canada25 as open source in the future)
  1. The core competencies of a community management organization are different from those of a software firm. Specifically, core competencies reside in their capacity to support and enable the community to collaborate and contribute to the project. Furthermore, the community’s contributions will not likely be limited to a single function (such as coding new features) but will need to include all aspects of the projects evolution including discussions about the direction of the software or marketplace and its impact on strategy. As people volunteer more time and become more invested my hypothesis is that they will want (at least) input (not to be confused with decision-making authority) in more strategic decisions.
  1. Consequently, the structures and skill sets of those working on an open source initiative need evolve over time:
    1. In the beginning, because of their size, open source projects can pretend to be software firms – this is because the community is sufficiently small that everyone knows one another so that levels of trust are high and the need for formal community structures are low. In this earlier phase:

i. Respect and influence is based on raw brain power/problem solving capabilities – rather than seek permission those who code solutions to problems earn respect, and others listen and/or follow their lead

ii. Common values and operating assumptions in the community are not, and don’t need to be encoded – it is small enough that those who ‘get it’ opt in, and those who don’t opt out.

    1. Success changes everything. As open source projects becomes increasingly successful (and, possibly, more political) the context around the community changes:

i. Success means more people join the community. This is not only true of the number of people, but also of the type of people (e.g. skill set, cultural background, etc…). This increase places stress on the community infrastructure. Specifically, an increase in participants can:

1. reduce levels of trust and the sense of community, raising transactions costs to effective collaboration

2. erode the assumed common community value as new entrants join the project for different reasons

3. decision-making becomes increasingly complex as the consultative nature of open source projects does not obviously scale. This may cause individuals/groups to feel disenfranchised and/or frustrated (and never underestimate the damage to productivity frustrated people can cause – thank you for this Shaver)

ii. As the product matures innovative leaps become harder. With the low hanging fruit plucked new features and ideas become harder to imagine and/or complex to code. The likelihood of one genius coder solving a problem is reduced. Thus at the same time that legacy governance structure (or lack thereof) makes collaboration more difficult, innovations become more difficult.

    1. Community Management as Cope Competency. My interest in all this is how we can take the ideas, methodologies and tools that come out of the negotiation/conflict management/collaborative decision-making arena and port them over to the open source space.

i. Training up in facilitation skills. Getting the core group of project employees trained up on how to collaboratively solve problems. Some basics might include:

1. using interests and not positions when resolving disagreements

2. using Chris Argyris’ theories about how (particularly smart technical people) fight over conclusions, by failing to share the data and analysis behind their thinking – often referred to as the ladder of inference.

ii. Rethinking decision-making processes – chiefly by setting expectations of how decisions will be made, what criteria will be applied when making them. It is likely essential to give community members a common set of criteria to use to evaluate decisions, that way they we can reframe discussion from what they like more to what adheres to the communities standards the closest. This is true for technical decisions, but also strategic or governance questions. The key around decision-making is not how democratic it is, but how well we set expectations for community members and then adhere to those expectations.

iii. Open source communities may fear accepting that even greater collaboration and openness is their core competency because it raises the underlying question no one wants to ask: Is the open source model scalable , and competitive?

The false answer is no: To believe that becoming more competitive and/or moving quickly means we need to consult less.

The true answer is yes. We can’t be competitive by running away from our core-competency, if we do that the we end up playing by the rules of the established corporate players, rules that we can’t win using. Forget their playbook, we have to get back in the box. We have to become faster, more efficient and easier to use at what we do best: engaging and enabling everyone in the community (customers, volunteers, etc…) to collaborate.

  1. Leaders Matter: The good and bad news is for project leaders – for example, paid employees of the project – is that you are THE role model for the community. Every action you take validates or invalidates certain behaviour types. If a employee behaves in an unconstructive way it will be hard to tell others in the community that this behaviour is out of bounds.

I suspect that most open source projects:

    1. Know this
    2. It causes nervousness
    3. Because participants are smart, we rationalize ourselves out of this problem

But… we can’t. And we shouldn’t. This is our single most important chip. It is what allows us to shape the behaviour and culture of the community. Let’s embrace it and use it.

Sorry for the long post – generated out of some thinking with friends at Canada25, Canada2020 and Firefox. Hope you have lots of thoughts, reactions and comments, definitely want to refine my thinking and there is likely a lot of refining to do.

UPDATE: If you found this piece interesting I’ve written a follow up on to this piece, entitled Wiki’s and Open-Source: Collaborative or Cooperative?