Tuesday, April 07, 2009

Good versus evil diversity - why the foundation must hire developers

In German we have two contradiction proverbs: "Gleich und Gleich gesellt sich gern" ("birds of a feather flock together" *) and "Gegens├Ątze ziehen sich an" ("opposites attract" *).

When applied to couples, I think both are true but for different aspects: for social status, education, religion etc, coming form similar background makes things easy. But when it comes to character, being of different kind is good because my partner might have something I don't have and together we are more "complete".

Diversity in open source is similar. There are areas where diversity is absolutely vital and other areas where diversity has a very negative impact.

Bjorn criticized the "lack of diversity" in the eclipse community because most projects are "mono-vendor". He is right, we need more diversity here!

But there is another kind of diversity that is bad: if there are many ways of doing the same thing. Excellent system are not designed by committee, but by a few people (often a single person) with strong ideas about architecture, design and the "right way of doing things" (Frederick Brooks calls this "Conceptual Integrity"). This leads to excellent systems. From my experience I learned that it does not matter much, which set of rules are applied, as long as the rules are consistent and everybody in the team believes in them and follows them.

Startup companies often get this kind of consistency "for free", because they grow form a small set of people and they hire only new people that fit into the "mind set" of the team. Open source projects, created by some enthusiasts, get it, because they attract people who believe in the system. The (original) eclipse platform is an example of such a consistent system.

I am afraid that the future of eclipse is in danger if this wrong type of diversity (I call it chaos) increases. (I wish the architecture council could help to defeat this kind of diversity, but I am afraid that the council is already way too diverse when it comes to "architecture")

It would help a lot if there would be a set of developers paid by the foundation coming form different backgrounds but with a common mind set when it comes to technology. If the foundation would hire people, I am sure we could find a great team of people that would be able make eclipse ready for the future.

Having a "vendor neutral" team of developers dedicated to the future of eclipse would give eclipse a boost. Else, I am afraid, eclipse is "auf dem absteigenden Ast" ("heading south" *)

3 comments:

  1. Interesting perspective. I agree that there is the possibility of "too much of a good thing" when it comes to diversity; but I'm not sure if Eclipse projects have reached that point yet. Maybe some have, but probably not all.
    I think the most important practical issue you mention is the "re-invent the wheel" syndrome; that is, there are simply too many ways to do the same things. I think a lot of that is driven by a stubborn resistance to make things public API, which in turn is driven by the "backwards compatibility at all cost" mentality. I do understand very well the motivation behind placing a premium on backwards compatibility, but I also have experienced situations where it was too strict and otherwise good ideas were abandoned or rejected because of it. That leads to many different wheels being re-invented, a sign of the bad kind of diversity of which you speak.

    ReplyDelete
  2. "Backwards compatibility at all costs" eventually leads to no forward progress because the cost of backwards compatibility becomes too high. The perl community is a good example of "no progress," whereas the php community took the opposite approach: as much backwards compatibility as possible, but not to the extent of stopping progress. Sure the result is a pain to use at times, but PHP is a lot more widely used than Perl...

    ReplyDelete
  3. Note sure if the foundation should hire developers. I could imagine, though. I'd like to keep that apart from the foundation. I say we need to refactor the Eclipse top-level project. The influence of too few still decides about the future for many.

    ReplyDelete