Parallel Feedback Loops: Integrating Your Community

I finally wrote something for the Hyperic blog:

The term innovation opportunity has been discussed by Matthew Aslett, who described it as "the potential to lower development costs for business users, while at the same time raising their potential to focus on innovative development." This falls in line with the view that an open model is more efficient, but how exactly is it more efficient, and how does one maximize that efficiency? Does Open Source development lead to the creation of a perfect market? I will attempt to describe how innovation opportunities come about, and how to take advantage of those opportunities. The key would seem to be enhancing the ability to deal with parallel feedback loops that arise as a matter of course from interactions with your user and developer community. Put another way, maximize the surface area of your community and be able to capitalize on these "touches".

Read the rest of Parallel Feedback Loops.

Stacey Schneider and Open Source as a 'Perfect Market'

As I await the impending cure for writers block (today? tomorrow? next week???) I thought I would shout out to my manager, Stacey, who wrote a great post entitled "Nobel Prize Implies Open Source is A Perfect Market" - an analysis of this paper by Eric Maskin, one of the recent recipients of the Nobel Prize for Economics for his work on Mechanism Design Theory. As someone who sincerely regrets never taking an econ class, this stuff is gold.

You should read her full post, but I'll note a couple of things. The quote she latches onto from the above-linked paper is this:

"...when discoveries are 'sequential' (so that each successive invention builds in an essential way on its predecessors) patent protection is not as useful for encouraging innovation as in a static setting. Indeed, society and even inventors themselves may be better off without such protection. Furthermore, an inventor’s prospective profit may actually be enhanced by competition and imitation."

The above applies specifically to patents, but the question is whether there's any application to open source software. Stacey's conclusion is that open source is software’s solution to creating the perfect efficient market, which is something to keep in mind the next time you hear anyone describe open source as "cancerous" or "communist" - not that anyone's ever done that or anything...

Read Stacey's post here

The Best Kept Secret in Open Source?

Here's a little test for you - quick, name the hardware vendor about which the following was said:

[their] commitment to providing high-quality drivers that meet the needs of the mobile Linux community is second to none.
- Matthew Garrett, Ubuntu Mobile Linux Engineer

I tend to suggest that... you buy [a machine] with [company's] graphics and wireless. That takes care of the 2 biggest annoyances right there.
- Linus Torvalds

(see source at the end of this post)

If you said "AMD" then you've been reading too many press releases. While it's nice that AMD appears to be making moves in the right direction with their ATI drivers, the fact remains that the only major vendor to release and fully support open source graphics and wireless drivers on Linux is... Intel. After speaking with Dirk Hohndel, Intel's Chief Linux and Open Source Technologist, it begins to dawn on me that we enjoy the fruits of Intel's labors, often without realizing it. While other vendors release binary blobs for their drivers, Intel has taken the total Open Source approach, with real working drivers available right now.

Perhaps lots of other people are well aware of Intel's contributions and I'm the only one without a clue, but somehow I doubt it. For a quick rundown of Intel's open source contributions, see this list, which I found at Matt Asay's The Open Road blog:

• EFI


• moblin.org


• Harmony


• Linux kernel


• Xen, KVM, UML


• LinuxPowerTop.org


• acpi.sourceforge.net


• openWSMan.org


• OpenAMT.org


• LinuxUWB.org


• LinuxFirmwareKit.org


• IntelLinuxWireless.org


• IntelLinuxGraphics.org


• Mesa


• X.org


• LSB

We are also participating in many other communities like MySQL, Apache, Firefox, and gcc, to name just a few. There are many more. Our goal is to ensure that people using open-source software have a good experience when running it on Intel hardware, so we are touching many different projects.

That's quite a list. I asked Dirk about making more noise about Intel's Open Source efforts. He mentioned the fantastic relationships that they have with so many Open Source projects, and that it's not in Intel's interest to screw them up - and the last thing they want to do is make the developers feel that they're doing Intel's bidding.

While I can understand this, I can't help but think that Intel is missing out a bit. Look at the goodwill that AMD has engendered with their recent announcements. While you could look at that as marketing fluff, I tend to think that the follow-up will be real. As I mentioned to Dirk, as long as you add real value to Open Source projects, no one can accuse you of marketing fluff. Thus, making a big deal out of Intel's contributions is simply making sure that the facts are reported to a wider audience.

While I am forced to admit that there's something refreshing about Intel's understated approach, I tend to think that the correct balance could lean a bit more to the loudspeaker side - without going over the top or hyping vaporware. But what really struck me about this difference in opinion is how much our PR sensibilities are a manifestation of the size of company we work for - Dirk is at Intel, a major multi-zillion dollar corporation that spans the globe. In that context, making hay over something as piddling as moblin.org or some modules in the Linux kernel source repository would appear odd and out of place. In my case, I work at Hyperic, a systems management startup fighting for PR space in a growing market with a lot of action. In my world, you let no PR stone go unturned. So when I hear about the gobs of code churned out by Intel and the fact that Dirk's group lets me run FlightGear at a good clip on my laptop, I'm naturally impressed and cannot understand why there isn't more noise about it.

So, I'll do my little part and hopefully more people will know about Intel's Open Source graphics and wireless drivers. In the meantime, applaud AMD for moving in the right direction and hope they one day reach the point of matching Intel's contributions.

* Source for quotes: Intel Developer Forum, 9/19/2007

Would Dostoevsky Use the GPL?

To GPL or not to GPL: What Would Dostoevsky Do?

"Thou wouldst go into the world, and art going with empty hands, with some promise of freedom which men in their simplicity and their natural unruliness cannot even understand, which they fear and dread- for nothing has ever been more insupportable for a man and a human society than freedom."
- The Grand Inquisitioner, Book 5, Chapter 5, The Brothers Karamazov

In "The Brothers Karamazov", Dostoevsky wrestles with many grand themes, including the above passage about freedom. The context of the above quote was a tale told through the eyes of Ivan Karamazov about the dangers of freedom and how it can ultimately result in enslavement. Without getting bogged down in details, I think it's pretty fair to say that Dostoevsky had some misgivings about modern perceptions of freedom.

You may be wondering what in God's green earth this has to do with the GPL. Lately, a few folks have written about the wonders of permissive licenses and the death of the GPL and how developers will migrate towards BSD-like licenses because of fewer limitations associated with it. Just as Dostoevsky warned us about the ultimate outcome of total freedom - oppression and totalitarian hegemony - I too worry about the ultimate outcome of permissive licenses like the BSD license. If you are not familiar with the basic differences between the BSD and GPL licenses, I encourage you to read them:

read the GNU GPL license
read the BSD license

To over-simplify the differences: the GPL has more downstream restrictions on how derivative works may be distributed, the primary one being that derivative works must also be licensed under the GPL.

I get nervous whenever large software shops talk up the virtues of a license with fewer protections of developer and user rights. In the linked articles above, there is talk of permissive licenses being the path of least resistance, with the premise that it's "easier" to gravitate towards them. My question is - easier for whom? Easier for the developers or easier for the companies who wish to make use of it without those annoying obligations to the greater free software ecosystem? As is often mentioned by others smarter than me, a scenario where developers gravitate towards permissive licenses makes it easier for companies to avoid community reciprocity.

A free software ecosystem works best when there are some limitations on what can happen downstream from the developer. In the case of the GPL, there are downstream limits on distribution of derivative works, among other things. No, it's not a perfect license, as the arguments over distribution and software as a service bear out. Really, the GPL serves to keep an honest person (or company) honest and is the best means available today for maintaining a vibrant, free software ecosystem over the long-term - and I include commercial as well as non-commercial projects in the mix. You see, as Dostoevsky attempted to show, the best kind of freedom is one with long-term viability, and that requires some restrictions to maintain order. It is with this in mind that I must respectfully disagree with those who proclaim the libertarian roots of free software. Certainly, I can see some libertarian elements of the free software ecosystem espousing the BSD license, but the GPL cannot be considered libertarian. Quite the contrary, it's designed to carry forward a moral framework by which users, developers, and companies can abide. That it seems to work out for commercial and non-commercial entities alike is testament to the genius of one RMS.

Personally, I think this is the right way to do business - and make money, to boot. If you didn't see it, you should definitely read about Marten Mickos' keynote from OSBC on why MySQL uses the GPL. Protecting developer rights isn't just some nebulous hippie ideology - those same rights extend to commercial free software projects, too.

So would Dostoevsky use the GPL? I have not a doubt :) I have written in the past about the long-term trends towards lower software prices and freely distributed software, but there is no such trend towards the protection of rights. That only occurs through the vigilance of the greater free software community.

The Most Irritating Question in the World

While I'm waiting on my brain to cough up the rest of the "Open Source Macro vs. Micro" series, I thought I'd post about the Most. Irritating. Question. Ever:

"OMG! Like, how are Open Source developers gonna get paid???"

...usually asked in some worrisome tone, as if Open Source developers around the world were, like, starving or something and panhandling on the street. So here's a quick test on the absurdity of this question:

1. Do you see lots more open source development than ever before?
(yes)

Ok, proceed to the follow-up:

2. Do you see open source developers filling homeless shelters and food stamp lines?
(no)

Well, gosh, I guess that solves that dilemma. And yet, I hear that question ALL THE TIME. In 1999 - 2001, sure, it was a fair question. After all, there was legitimate hypothesizing that open source was fueld mostly by the .com bubble. I never believed that, but the concept was new enough at the time that I can see that as a plausible explanation. But now, going on 7 years after the dot bomb? No way.

Frankly, I just don't understand why the question still pops up. Nor do I understand the usual companion question/statement: "OMG! Red Hat, Canonical, and <insert company here> make money off the backs of free labor from individual developers!" 1.) I don't see why anyone is concerned if an open source developer is monetizing their project and 2.) I don't believe it's true - I think Open Source developers do, in fact, make money. Let's look at Red Hat, a well-known example of an Open Source company - they make money off of many open source projects because they can. Because they've built a reputation around their ability to deliver such projects in a form that is readily digested by their users. Customers find value in this, which is why they pay for it. So what of the individual projects that comprise Red Hat's distributions? What if they don't get paid? Assuming they don't get paid, you can really only point to one reason: because no one thought it was of high enough value to pay for it. Whether or not Red Hat is in the picture to make money off of their distribution and support is immaterial - either way, this hypothetical open source project is not making money. However, *with* the existence of Red Hat, suddenly these open source developers have a conduit to a rather large audience and now have business opportunities that would not otherwise be possible. In fact, if you take a look at Fedora or Ubuntu these days, you'll find lots of software that is directly supported from various companies for various reasons - and some that isn't.

If developers don't get paid, it's not Red Hat's (or anyone else's) fault. I don't actually believe that open source developers work for free - in fact, I think the vast majority of developers get paid in some form or another. Those who cut their teeth on personal projects will surely be able to parlay that into some form of employment in the very near future. Or they're paid by their company to work on a side project that's not a core piece of software. OR, as is increasingly true, they work for a company that sees the light and pays them to work on their core product, which happens to be Open Source.

This is not rocket science. The early open source nay-sayers often contended that open source wouldn't last because no one would get paid for it. They were wrong then, and they're wrong now.

Snoopy-dancing on SCO's Grave

I just got the news of SCO's passing - well, ok filing chapter 11 bankruptcy under the guise of "protect its assets during this time." One can't help but think that they see the writing on the wall and are doing this in anticipation of a slew of lawsuits. A lot of people have lost money on SCO and might consider their statements over the last 4 years to have been, shall we say, less than fact-based. That and the fact that they've bled cash for years and can no longer sustain their current loss rate.

This is an important day, and it's a time to reflect on the actual fallout from the case. One thing we must keep in mind is that the actual case SCO brought forward in court was far different from the case they fought in the press. Their press statements for over a year were all bravado about how Linux infringed on their IP and they might have to sue all Linux customers... or some such. Recall how some Linux users actually bought a SCO license, including Sun. If Sun were ever to meet this issue head on and describe why they helped fund SCO's war chest, now might be the time to do it. And, of course, you can't discuss this issue without also bringing in David Boyes, Microsoft, IBM, Novell, the BayStar Capital fiasco, Sun, Groklaw, Pamela Jones, Maureen O'Gara, Darl McBride. Shoot, I could write a 5-act play with all that stuff :)

The number of personalities involved is truly epic - but was the end result so epic? Well, I tend to think so, for precisely the same reasons that others think it wasn't epic. It was epic because nothing happened. It was epic because it showed 2 things: 1. Linux customer adoption would continue with or without SCO's support and 2. Linux != open source. For the former, we may never know in real $$$ whether or how many companies refrained from using Linux as a result of this series of lawsuits. For the latter, we saw many many more open source technologies rise in prominence even when the SCO litigation may have been in doubt in the minds of some.

So I will think about what has transpired, read Pamela's (deserved) gloating on groklaw, and wonder if others will follow in SCO's footsteps. I can't imagine that this is the last litigation we'll see of a successful open source project. In fact, I can see the success of various open source projects making them large targets. One thing is clear - whoever sues next will glean much from this episode.

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.

What is Software Commoditization?

I was reading Stephen Walli's blog, as I often do, and came across one referencing a presentation by Brent Williams on the topic of "Open Source Business Models: A Wall Street Look at a Wild 2006 and the Prospects for Even More Fun in 2007", with the slides (PDF) posted here.

What particularly caught my eye was Stephe's comment about Williams' "tear down of the commoditization myth." After reviewing the slides, I see that Williams truly possesses a great intellect and analytical ability. I can only hope to see him make a presentation in the near future! However, I get the sense that when I use the term "commoditized" to describe cheap software bits, it doesn't exactly fit the term that he's tearing down in his slides. I would seem then that when he debunks the idea of commoditized software, we're actually talking past each other and arguing purely on semantic grounds.

My view on commoditized software has been that, with the proliferation of coders and more code distributed throughout the massive expanse of the internet, we see an emergence of low or no-cost programs, libraries, and other bits of code that other developers and IT professionals can latch onto, either as is or stuffed into a complex composite application. This model treats bits of code as reusable parts that a decent code jockey can then make use of, so that developers can bypass the grunt work often associated with coding and jumping almost directly into the more interesting work. The end result is a cheaper development process and, IMHO, downward price pressure.

This model assumes a bunch of stuff: 1. that the code is pluggable enough to be inserted into other software and 2. that it's of decent enough quality. Often, either or both of those statements are not true, which takes the developer back to square one of building everything from scratch - or does it? Williams' slides really made me re-think the whole term commoditization: is it the code or the knowledge of the problem's solution that has been commoditized? We can all imagine software as a pluggable commodity, but what if it's not the software itself, but rather the knowledge gained by seeing another solution and using the logic as a starting point?

While it's important to note that "commodity software" doesn't fit the traditional definition of commodities, I'm not sure how useful such word-splicing is. I suppose it's better instead to come up with a word that can describe "software depressed in price by an abundance of implementations AND implementors." I would actually argue that it's the latter that's of primary importance here - after all, doesn't the potential of others to implement a feature set depress prices just as much as an actual implementation? Do all ISV's build in this "fear of the near future"? And with the internet, that fear mushrooms when you think about the prospect of hundreds of knowledgeable people around the world *potentially* working on similar solutions as you.

Compare software and science - would you argue that the theory of relativity is a commodity? Probably not, but it's a known quantity. The practical aspects of relativity have been known for some time now, although the theoretical realms may still be under discussion - I actually don't know, not being a theoretical physicist. But this captures the essence of my definition of commoditized software - something that's been done and from which others have derived a basic understanding of how it was put together. The knowledge of relativity could be categorized as a type of intellectual currency with real value, just as the knowledge of software building blocks also has real value. Yet, no one assumes that someone who understands relativity is another Einstein, and no one assumes that those who understand software building blocks are Kernighan and Ritchie. Basically, I'm talking about the trickle-down effect as applied to knowledge industries, and software development is no exception.

So yes, commodity is probably a bad word, but there needs to be some sort of terminology for "been there, done that" or perhaps "several others are about to be there and do that."

Edit at 4pm PDT, by JM: added paragraphs 3 and 4 to explain in more detail the concept of commoditization

Open Source Macro vs. Micro

When I've written about the inevitable march of Open Source, there are a couple of things I've failed to note, or that I just got wrong. One of those is that I conflated the issues of open technology trends with Open Source. While both are trending upwards, they are certainly not the same. The central premise that I've advanced before still holds - that is, the internet has led to unprecedented downward price pressure on software, thanks to a market flooded with software and software developers, with the added bonus that they can all collaborate with each other in "real time." This serves to accelerate the development of software, creating a vast, fast-moving pipeline of new features over a broad swath of software markets. As opposed to traditional software feature pipelines, this one is almost self-correcting in that the users, developers and user-developers are in constant contact with one another, adjusting the pipeline as it moves along. This part is boring. At the risk of patting myself on the back too much, my assertion has been proven correct many times over.

No, where I got it wrong was in equating open technology and the trends in that direction with Open Source, as defined by the OSI. Sure, this downward price pressure makes the current open source ecosystem viable, but that's not nearly the same as saying that trends towards openness will necessarily result in an Open Source end. The truth is, there is a wide range of points on the open spectrum. As it stands, I've written a great deal about "macro" open trends, but not much about what happens on the "micro" level. With this post, I'll kick off an attempt to do that.

One point on the open spectrum represents the ideal of Free Software, governed by an overt moral ethos, whereby all players are expected to share alike as a means of building a better technology world. At another point lies Open Source, as defined by the OSI, which is kinda-sorta governed by the same moral ethos as Free Software, but they don't really like to talk about it much, for fear of chasing away the very companies they're trying to attract. And at many other points on the open spectrum lie all sorts of technologies that are neither Free Software or Open Source - even if they have adopted a licensing scheme endorsed by both.

These other non-Open Source and non-Free Software technologies develop a degree of openness for all sorts of competitive reasons. Witness, for example, how Microsoft is attacking the RIT market or web services. In both cases, they have had to be open in order to stay competitive. While Microsoft may end up using an Open Source license in some cases, they often do not, but they still want some of the benefits of openness without giving up too much control. In these cases, Microsoft clearly wants to grease the skids of adoption and lower barriers to entry. There are also startups that wish to tap into open trends, with some coming under fire for using the term "Open Source" without using an OSI-compliant license. While they shouldn't use the term Open Source without conforming to the Open Source Definition, they should at least define their work in such a way that differentiates them from traditional enterprise software plays.

Trends vs. Personal Experience

It's one thing to say that the overall trends favor more open technology and Open Source, but what about on an individual level? What do these trends say about individual projects and their chances of success? The answer, it turns out, is not much. All the open trends in the world won't save a bad project. At this level, it's really all about emotional attachment, warm fuzzies, dynamics of the project leadership, and any number of other factors that lead to more people gravitating to community X over community Y. It is within this "micro" sphere that factors such as project personality, license choice, degree of openness, and yes, project ethics come into play.

It is at this level that community leaders will have to consider the audience they want to attract. Does your desired audience often seem paranoid and overly cynical? You'll have to work extra hard to woo them, and you'll probably need to start with the GPL or even a BSD license. That's not the final step, however. To truly give them warm fuzzies, you'll have to consider their cultural priorities. Will they naturally gravitate towards organizations like the Electronic Frontier Foundation or the Free Software Foundation? If so, you should probably at least consider some form of relationship with them. Making statements about their pet issues wouldn't hurt either - the OOXML debacle presents a great opportunity, as does the recent controversy over what Open Source means. Opining on the tactics of the RIAA and MPAA might help, as well. Of course, these are only suggestions for a certain audience - the ones with laptop stickers that say "corporate websites suck".

I wish I could calculate how much it's worth for a company or project to engage in this sort of cultural activity, but I really can't. It most likely won't help with the enterprise IT buyer, although it's good to remember that they are people, too. Regardless, it's a good rule of thumb that when you're trying to attract an audience, it's good to know what things they care about the most. As has often been noted, it's not enough to open your code and throw it over the wall. I would add that it's also not good enough to woo the audience with just technology - there has to be some force of personality and a willingness to participate in some cultural issues.

Matt Asay Asks: Should You Ever Fire a Community Member?

Matt asks the question that comes to every online community manager's mind at one time or another, even if they never voice it outloud: "Gosh, life would be so much easier if I would just tell userxyz to get bent. After all, he/she never adds anything of value to the conversation, and they just drain everyone's time."

It's such a tempting proposition - and one that each community has treated differently. Back when Marc Fleury ruled the roost, JBoss forums were notorious for their low tolerance of newbies who didn't RTFM - or so I've been told. At an Open Source community managers' meetup at OSCON, perhaps the most cogent statement on the subject came from someone whose name I've unfortunately forgotten: the first time someone asks a question, be very responsive; the next time, take slightly longer; the third time, even longer, and so on. The thinking is that this approach encourages users to think for themselves.

In fact, it's a lot like parenting. Reward good behavior; punish bad. Sure, you *can* go negative (yelling, physically punishing child) and reap the short-term benefits of immediate obeisance, but you may end up laying the groundwork for more work in the future. It's better to make sure good behavior is properly rewarded, thus giving all members a clear indication of what behaviors the community encourages and those they will not tolerate. Sure, as community manager, you can ex-communicate whomever you please, but that doesn't exactly set the tone of trust that you want the rest of the community members to feel. As Matt notes, it might lead others to conclude...

what would those other 95 percent think if they saw a community member--even an obnoxious one--dumped from the forums? That doesn't sound like the sort of community I'd want to join, where your voice is only valid if you happen to be singing in tune with everyone else.

The community manager's role is to make sure that no one becomes a nuisance, so that does require some active participation, but not outright antagonism. The challenge is to nurture a culture of respect, where users will naturally shun those who are potentially abusive. The community manager must actively set the tone and demonstrate the rules of engagement for others. Eventually, those who earn the "annoying" mark will either shape up or ship out.

The Unspoken Morality of Open Source

It has long been my opinion that open source is fueled by an unstoppable economic phenomenon - downward price pressure as a direct result of the growth of the internet (and thus growth of collaborating developers) and the ensuing commoditization of software features. One of my central beliefs is that, all else being equal, being more open can be used as a competitive advantage. This is why I've always thought open source is very much entrenched in modern computing and will only grow from here. In a competitive market, one of the ways to differentiate yourself from the competition is to be more outwardly-focused, collaborative, and willing to open up your development processes. It's not that opening your code is a nice thing to do - it's a means of survival in today's IT market. Can you name a single IT startup in the last 3 years that didn't have some sort of "open" strategy? Exactly. Even the closed-source ones borrow heavily from Open Source-style community building and developer relations.

However, in describing the trends toward "open," the devil is in the details. Unfortunately, when originally thinking about these issues, I didn't include in my calculations all of the various gradations of "open." Furthermore, I tend to have a fairly binary view of the world - software is either Open Source or it is proprietary. As recent software licensing arguments have demonstrated, the current environment begs a more nuanced view. One can't simply look at the field of "open" companies and conclude that they are willing to fall in line with the OSI and their definition of Open Source. In a world where companies are described as either Open Source or proprietary, a company that falls close to the "open" end of the spectrum will naturally use Open Source to describe itself, even if it's not completely accurate.

This brings up a legitimate question: what then, should they call themselves? They're not traditional proprietary companies, so lumping them in with the likes of traditional ISV's doesn't seem right. It would seem that the obvious solution is to come up with a set of terms that describe companies more open than others... but not exactly "Open Source." For the record, I think it makes sense to have a strict definition of Open Source so as not to confuse the market. But there is a larger issue - why hasn't the OSI taken a leading role in providing an umbrella taxonomy for these companies?

To answer that question, you have to consider the origins of the OSI and both its stated as well as unstated goals. From the beginning, "Open Source" was pro-business spin for "Free Software" - without the baggage of the Free Software Foundation, its fanatical devotees, and that crazy hippie, RMS. To say that Free Software has a moral component would be an understatement. Open Source got its start supposedly as a better, pragmatic way to develop software in comparison to the traditional proprietary approach - more reliable, better security, and a high rate of innovation. But there was a moral component present in the definition of Open Source that went largely unspoken. Reading the OSD, it becomes clear that its authors wanted a fair business ecosystem whereby everyone plays by a set of rules, and certain types of behavior were definitely frowned upon. Preventing the forking of code is one example. Requiring the original author's logo be displayed in derivative works is another. These were discouraged by the OSI founders not because they felt it was in a company's business interest, but because they felt it was not a virtuous way to conduct business.

However, that aspect of the OSI and Open Source went largely unstated, and it generated much confusion in the market. Here was the organization that controlled the definition of the term Open Source, stating that their primary reason for being was to create a business-friendly ecosystem around Open Source software, and you had certain businesses and developers that didn't necessarily want to play by those exact rules wondering why the OSI wasn't being flexible. The reason, even though it wasn't really stated, was because those companies and developers that wanted to skirt certain parts of the OSD did not meet the OSI's moral standard.

Over the years, I've begun to feel that emphasizing the pragmatic aspect of Open Source at the expense of the moral was a mistake, especially when the moral aspects fuel so many of the current debates. There are many software vendors that wish to be more open and want to identify themselves as something that's not the same as traditional proprietary softare, and you can hardly blame them. They have been led to believe that Open Source is something that describes anything that's more open than everything else. The OSI has to find a way to accomodate these folks without diluting the term Open Source, but they can't do that until they publicly acknowledge the moral component of the OSD. It is better to acknowledge that it exists and eliminate any confusion as to why certain practices are not allowed. Then the OSI can perhaps accept the challenge of creating a fair taxonomy that doesn't simply describe mostly-open software as "not Open Source."