Reading some (but not all) of the Firefox/Thunderbird discussions, I find myself sanguine. I am not finding anything to be upset about. I think the current discussion may be more about the social structure of Mozilla. It does not seem to be a technical issue.
Looking at the technologies, it might be helpful if MoCo became, or came to see itself as, a service-provider for projects like Thunderbird. It could be "sourceforge with benefits", or perhaps a "sourceforge with a conscience". This seems obvious.
What makes it hard for MoCo to deal with Thunderbird as it is right now? Open-source avoids some problems one sees with commercial development. Commercial development seeks local maxima of utility with minimal investment of money. But MoCo has a similar issue. It seeks local maxima with minimal investment of social capital. What does this mean? If one looks at how Mozilla works, one sees this played out in many ways. I see some of them, but I do not think I am the best one to call them out.
One can identify, though, the "Mozilla way" of doing things. I noticed this when I was at Apple, and I still see it today. The "Mozilla way" is to use quirky tool sets, often old tools sets, with lots of hand-crafted modifications for particular issues. Enabling flexibility in these systems is not often a priority. Often it seems to be easier to hand-craft a solution to deal with the hand-crafted solution from two years ago. Finding a general solution that does not require tweaking does not seem to be a priority. A general solution rarely has social benefit. Individual tweaks, each to satisfy a different social entity, do have social benefits.
Why are more things not better documented? There is no social benefit to documenting that which is known by the core group. MoCo has, in general, a resistance to making things obvious. But social networks are built on shared knowledge, and if that knowledge requires a "maturation ritual", a "rite of passage", to find, all the better.
So, why can't Mozilla keep Thunderbird up-front, alongside Firefox? Perhaps it is not a technical issue. Anthropologists tell us that primates form social networks whose size varies with the ration of the brain size to body size. Given MoCo's reliance on social cohesion, Mozilla may not be able to concentrate on Thunderbird because the social network required is too big. Is Mozilla's pervasive reliance on social cohesion a good thing?
Subscribe to:
Post Comments (Atom)
5 comments:
No fair- when writing about the thunderbird decision, blog entries should only discuss the importance of email, cast aspersion about the influence of Google and debate the three options for Thunderbird's future structure.
Instead, you're examining an issue fundamental to Mozilla that's both a source of strength and weakness and will profoundly influence its future. Shame on you.
Um. What? Is this a serious comment or a joke? I hope it is a joke....
Tau, that was sarcastic.
> Um. What? Is this a
> serious comment or a joke?
> I hope it is a joke....
>
It was a joke- I'm doing a poor job of kicking my sarcasm habit.
The analysis in your original post is spot on. While most other folks wrote about email clients, you did a good job articulating the deeper, more fundamental issue that Mozilla has wrestled with in the past, is wrestling with in the present and will wrestle with in the future.
> Is Mozilla's pervasive
> reliance on social cohesion
> a good thing?
>
I'll only echo your observation it's fundamental to the organization and that good or bad, because it's fundamental, change it and you change Mozilla.
As a longtime observer in the peanut gallery, watching the Mozilla organization evolve has been fascinating...and it looks like things will stay interesting
Assertion: Social cohesion is one way (the only way?) of keeping an open source project governable and moving forward.
If disparate groups form, especially if members of each group are in positions of power, infighting begins. In a traditional software company, what prevents this from going out of control is top-down management who are able to mediate discussions.
In some projects, there is a replacement for this: the concept of a BDFL (cf. Linus, Guido, et al). A leader who's authority cannot be challenged, who can act as a moderator to disputes, and can set project direction.
Smaller projects may not need such a leader -- common interests and familiar social constructs (cliques) help regulate things to achieve focus (or in some cases things end up falling apart and people leave due to differences).
When you find a project as big as Mozilla with no real clear, high-touch BDFL, you need an alternative structure. The module system of owners and peers are one way, but the poorly documented and arcane mysticisms that form our current process are part of a social reaction to try and keep the group intact from foreign influence.
I'm not sure how you "open up" and make it easier for new contributors, but wikimo and devmo are a great start. And there is definitely a movement within Mozilla to try and be more open -- fighting the intrinsic social pressures to close things off. Also a good start.
I enjoyed this blog entry, Ray. It's great to hear your insights on these sort of things. Any suggestions on how to improve things? :)
Post a Comment