Inventor's Disease

This is about 9x and being less brilliant.

Many have heard me babble about 10x, or the idea that we should grow the world of Zope by a factor of ten in the next year. Getting there, though, might require not just more work, but different work.

The book "Crossing The Chasm", which I talk about incessantly, segments the adoption of a new technology into a bell curve with five groups of people: Innovators, Early Adopters, Early Majority, Late Majority, and Laggards. Each group has a common psychographic profile: they have the same goals and make decisions using the same kinds of critieria.

One challenge is that, what works with one group doesn't work with another group. The first group, Innovators, love technology and have no budget. You need them to get word of mouth and initial credibility. Early Adopters want the revolutionary increase in productivity from a new technology and they have a budget.

Then you hit the problem. The Early Majority starts the big part of the curve. They are open to technology, but more risk adverse. They want to know more about who has already used the technology, the long-term plan, etc.

The Early Majority is also the domain of Joe Professional Programmer. JPP isn't religious about individual technologie, he wants to use the best tool for the customer and also wants to keep his resume attractive.

Reaching these people is a challenge for open source projects. We just aren't good at talking to them. Instead, we are more concerned with the needs and motivations of the 1x, and the 9x are somebody else's problem.

I'm particularly concerned about the inventor's disease. It's fun and rewarding to invent something new. However, there's only so much innovation that 9x businesses and JPP can accept before it feels too different and risky. And this is a motivation that is unfamiliar to the 1x people, for whom this risk is the very attraction: "Look, a puzzle!"

JPP and 9x businesses do a cost/benefit when looking at a new technology. First, they have invested a lot in acquiring skills: programming languages, databases, query languages, templating systems, object models, etc. For some new system, how much of that investment can they leverage?

Second, each new thing they have to learn is, indeed, a cost. The more they have to learn, the higher the cost. However, if that new knowledge can be applied for other systems (meaning, it is a standard they would probably learn anyway), then the cost might have an acceptible benefit.

Thus, there is a challenge in balancing the innovation of a disruptive technology, vs. the cost/benefit head-scratching JPP is doing. "I've never seen this before, and I'll never see it again" is a de-motivator for 9x and JPP.

In a way, this is similar to a motivation in "Don't Make Me Think", a great book on web design that also cautions against revolutionary web interfaces. The reason is similar: people have, somewhat painfully, acquired certain skills that they would like to put to use. If your website, or your system, doesn't fit any of these patterns, then you will lose an important segment of the audience.

Thus, 9x and JPP are about being smart, but not too smart. Also, about fitting their brain, not exploding their brain.

In working on Moztop, I'm trying to re-earn some credentials in developer-land. It's making me better appreciate the trade-offs that have to be made. What do you do when two strategies are conflicting and equally valid? For instance, you might have an approach that is really alien, but offers really compelling benefits. Keep it or toss it?

For Moztop, I'm going to err on the side of tossing it. In many ways, I don't want to be smart in this project. I want to be anti-smart, which suites me just fine. :^)

There's already plenty of brilliance already laying around us. Perhaps an overabundance of brilliance, due to a "selfish gene" effect, where we have to get our meme out into the body collective.

That's a real goal of mine for Moztop. I don't want to invent a single new protocol or standard. Even if it is harder for me to implement an existing protocol, so be it. Less brilliant, onwards.