A post I wrote last week called into question the difference between “good community” vs. “good company”. Matt thinks I have a vested interest in calling out JBoss’ community cred. I think I have a different view of community vs. company. Sacha Labourey comments to point out that JBoss is focusing more on community, which is great. More on this in a future post.

I’ve previously written about why I feel tension between doing what is right for “the community” vs. “my employer” is what makes for a “good community”. Maximizing the former is obviously good, but the debates that result from the latter often lead to better ideas which in turn help the former

Let me recap with a picture that highlights my box drawing skill:

Once a company starts hiring, and as a result, controlling, the majority of developers who were contributing to an OSS project, the result begins to look more like a company developing in the open and less like a good community. This is especially true when a company hires the “best contributors” not already working for said company.

To illustrate, let’s take Oivas, a fictional application developer working at Acme Inc. He is using JBoss AS at work and realizes there is a bug or missing feature. He writes some nifty code and contributes his work appropriately. Repeat said process until JBoss Co. notices, decides they like Oivas’ work and decides to hire him. Oivas accepts.

First, “the community” loses because Oivas is not able to draw upon his daily job for ideas to contribute because he is no longer an using JBoss AS daily (he’s developing JBoss AS). That’s likely not a big deal because other users can keep Oivas busy with bug/feature requests.

Second, Oivas is working towards the product features and deadlines that his new employer sets out for him. What if he thinks that the integration of JBoss AS with an IBM product or a Microsoft product would be just what his friends at Acme Inc. or the Acme Inc.’s industry needs? But sadly, JBoss/Red Hat would rather Oivas work on things that drive customers to other JBoss/Red Hat products. Now, there is nothing wrong with JBoss/Red Hat expecting that their development dollars get devoted to work that drives potential usage of JBoss/Red Hat products. But in such situations, the goals of JBoss/Red Hat don’t align with the community or customer needs.

Lastly, how does the JBoss community decide whether something like Red Hat Development Studio is the best thing since sliced bread and should be advantaged over other alternatives. (I’m not arguing one way or the other). In the absence of a community of developers with decision making abilities, with different employers, representing differing motivations, they don’t. JBoss/Red Hat makes the decision and 3rd party developers & customers have to live with the decision from JBoss/Red Hat. This is not unlike decision making in a traditional software company and the result on customers. But the traditional development model doesn’t claim to be a community model.

He who pays signs your paycheck gets a reasonably large say in what you do during your work day. A group of people whose paycheck comes from the same entity constitutes more of a company, than a community.