Open Source Macro vs. Micro - Part II

As I mentioned in my previous post on this topic, Open Source and open technology trends continue to swing in one direction (up and to the right). Along this ever-growing open technology spectrum lie various projects and companies who hope to gain a competitive advantage through some type of open collaboration initiative. Within this spectrum lies a subset of this group that I call the Open Source ecosystem. I've mentioned elsewhere why more companies are gravitating towards an open technology and Open Source model. In this document, I'll follow-up on my last post and explain in more detail what it means for a project to win over the hearts and minds of an intended audience. The basic question may be phrased as thus: why does "joe user" or "joe developer" gravitate to one project or technology over another.

Note that a given online community comes with its own biases, ambitions and desires, and these wildly differ from one online community to another. The community type with which I'm most familiar and the one that defines the context of this post and others, is the Open Source type of community, with its demands that projects and companies live by a codified set of rules as defined by the Open Source Definition. The Free Software community also lives in close proximity to, if not within, the Open Source ecosystem, given its similar requirements and moral framework, although these could be described as more stringent than Open Source. This is the context with which I'm most familiar.

It seems that there are two basic attractors that define why someone may gravitate to a specific place on the internet and call it 127.0.0.1. One is the technology basis of a given software project, and the other is harder to define. For lack of a better description, it's the sense that this particular project or group of people is not simply trying to make better technology but also trying to make this a better world (I can hear the groans now... bear with me). I'll simply label it as the cultural attractor. So we have two attractors: 1. technology - ie. is your stuff up to snuff? and 2. cultural - ie. technology is nice, but where does it fit in the larger context of the world?

The Technology Part

You might think that the technology attractor is the easiest to define: it's not. There is a ton of good techology that makes a poor basis for an open source project. OpenOffice.org comes to mind - it has many thousands of users, but the fact that there's any collaborative community at all around that project is mostly due to the sheer willpower of Sun and the OpenOffice.org community leaders. This is not meant as a slam on OpenOffice.org - I just want to point out that it was never very hacker-friendly. It wasn't the type of project that a developer or scripting guru could do much with. A project like KOffice or even Gnumeric would probably be much more fun for your average "joe developer".

To me, what defines a project ripe for Open Source collaboration is one that's not quite feature-complete or fully formed, has many interfaces to allow for collaboration from any developer's preferred language, and is broken into small, modularized bits. The Linux kernel is a good but not perfect example - it's a great starting point for the various Linux-based distributions to add their own kernel improvements, and it's modularized enough to allow developers to focus on one particular aspect. Firefox is another good, but not great example - the developer interfaces have allowed for some amazing extensions, and the project has been the basis for a variety of commercial software efforts. These three aspects can be summed up in one word: hackability. If a project is hackable and gives developers room to play, while also giving users a real platform do to stuff, then that's a good start.

As I noted in my previous post, however, the technology part is not the sole definer of success or failure for Open Source projects - there's also a cultural aspect that is often poorly understood and yet almost but not quite as important as the technology itself.

The Cultural Part

The basic question here is: will I feel good about myself if I devote time to this project? This is the part where many projects and companies fail to capitalize on their community. This type of cultural attractor could be as simple as the personalities of the project leads and their abilities to inspire current (and future) collaborators. Or your project collaborates with groups only indirectly related to your core technology. Or perhaps you wish to contribute to some organization involved in information rights. All of these can contribute to the essence of your community feel.

Some companies have more tolerance for risk than others, so for them, engaging in activities which may or may not generate direct revenue is worth doing if they can see real benefits. My point is that this type of activity isn't all that risky, and it's not actually very expensive. Sponsoring user groups and user group-driven events is pennies on the dollar compared to traditional sponsorships for formal trade shows. Putting your name on the list of sponsors of a well-reasoned political initiative, such as getting governments to use open formats, only seems risky at first glance. Contributing to groups that aim to protect the rights of developers and users also gives off a nice warm glow - and would it be too cynical of me to note that any SEO professional *loves* incoming links from those types of organizations? There's a lot to be said for this type of activity and, frankly, I often wonder why more companies don't do it. The poster child of cultural attractors? Well, stay tuned for that one ;) This post is getting a bit long, but in the follow-up, I'll list some specific things that companies have done to engage with grassroots Open Source-related groups, and what happened as a result.