Tuesday, June 1, 2010

Component Teams as Open Source Projects

I share Michael Cohn's principle: component teams are not good and that they should be avoided [1]. One way I've been considering lately to avoid component teams is to create what I call private open source projects.

Component teams are attractive to software developers. They make them feel that their component is a software product. This sentiment is a good thing if it wasn't for the company not being in the software component business. Such an arrangement may lead to feature bloat and lack of focus on the company's core business.

The private open source model has all the same benefits of the public one, the main difference being the size of the community. In a private model the community would be restricted to members of the company.

The private open source model would require the same type of collaboration infrastructure privately that public open source projects create externally. The component team could then be reduced to a few part time committers. These would be selected by either meritocracy or management appointment.

The project that needs a new feature added to the component would either provide the feature itself, or fund a team to do it (Just like the commercial open source model). The committers would then review the proposed changes and commit them to the shared code base.

The private open source model ensures that features being added to the component are relevant to the business and not developer favored features.

Even when a component team exists, allowing others to contribute might be good. The next time the component team needs to expand, for example, it might consider hiring a contributor outside of the team.

Let's look at the downsides of such a model.

The committers might have a diverging idea of what the technical direction for the component is than the rest of the community. This conflict could result in fragmentation of the community and forks. In the past, external communities experienced forks that eventually got resolved e.g. the xfree project). In an internal community this possible fracture could mean that a component is no longer shared, as the community might not be big enough to sustain two projects. Hopefully, due to the homogeneity of the community the fragmentation risk will be low.

There are times when the crowd is wrong in vetoing a specific idea [2]. The worst case would be a disruptive innovation being discarded because the community doesn't understand it well. A mitigating approach is to have an incubator area like the Apache Foundation and others.

There might not be a community large enough to sustain a successful open source project. In some cases the component in question might be shared across multiple projects, but not multiple teams.

As with public open source projects, a complex code base might serve as an inhibitor to contributions. Another common complaint about public open source projects is the lack of documentation. A private one might suffer from the same affliction.

Sharing a reusable component is important and we should strive to do so. Just be careful with the creation of component teams as they might be hard to undo.

[1] http://blog.mountaingoatsoftware.com/nine-questions-to-assess-team-structure

[2] http://en.wikipedia.org/wiki/The_Wisdom_of_Crowds

0 comments:

Post a Comment

ShareThis