The Rule of Seven

ziggy on 2004-08-06T15:49:59

At OSCon last week, I got an idea I'm calling The Rule of Seven[*]:

When you don't have one clear solution to a technical problem, you get seven.

This pattern is all over the place:

• Instead of one Linux distributor we have ~7
• Instead of one dominant release of RedHat, we have ~7
• Instead of one template framework on CPAN, we have ~7
• Instead of one dynamic programming language, we have ~7
• Instead of one relational database engine, we have ~7
• Perl has a simple, clear object model. Tcl doesn't, so it has ~7 object-oriented extensions
• ....

Sometimes this is good. The industry is a big space, and there are lots of incompatible requirements -- high availability, high throughput, small code size, high interactivity, small devices, universal access, etc. No one solution can hit all of those points, so having ~7 choices in a given domain is a good thing.

We're also evolving as an industry. There are entire classes of problems we don't know how to solve, or solve well. Globally distributed architectures is one example. Having multiple competing solutions helps, because it we learn from each other and evolve over time.

Then there is the gratuitous proliferation, like Milton Ng described in his keynote last week. He wants to standardize his renderfarm on one version of RedHat, his vendors only support another version of RedHat, and RedHat's new licensing is moving towards pushing him towards a third version. It'd be nice if everyone could just agree on something that just works for the customer, but it's getting painful (and expensive) enough that it's almost worthwhile for Weta to plow some serious coin into open source development so they can run their lab on their terms, instead of dealing with dueling software vendors.

*: Not to be confused with The Rule of Four, which is something completely different