Weblog

Wednesday November 14, 2007

Popularism Software Engineering

In most other open source communities, whether or not something happens is a reflection of the desire of people to make something happen by spending time on a project. So if it is a good idea, the idea itself leads to change without anything specific needing to happen. If an idea is particularly bad, this will generally be pointed out at some point in discussion, whether this is when the idea is being floated or prior to integration. OpenSolaris has invented a new mechanism for determing whether or not a project gets the thumbs up: voting.

Integration of voting into the formal structure of an open source community is at first the means to formally record the explicit desire of an open source community. This works so long as those eligable to vote do indeed vote. However it introduces a new risk for projects: it requires that the person introducing the project actually be popular enough within the community to attract votes - visibly casting a positive vote for an unpopular person (regardless of the technical merit of a project) may carry social ramifications that voters are unwilling to take on. Thus the software engineering is subject to how popular the principals are and hence this leads to popularism software engineering.

There's another risk associated with this too: if the person proposing a project is perceived as being too popular or that is necessary to be seen to be supportive of said person through positive votes, it becomes increasingly likely that poor positive decisions will be made about what projects are approved. Thankfully OpenSolaris has an ARC (Architectural Review Committee) that is required to review proposals for architectural change (this is the case with nearly all projects) which diminishes the possibility of popularism voting for projects leading to their eventual delivery into the code base.