"Release early, release often. And listen to your customers."
Eric S. Raymond (esr) wrote those words in his 1997 essay "The Cathedral and the Bazaar," and, for a lot of people, they have become the mantra of the open source software movement. While this advice might seem obvious to many, that doesn’t make it any less important. In fact, I’ve often benefited from esr’s maxim myself, and I’ve even come up with a shorthand for why it works. I call it the "practice effect."
The Practice Effect is a 1984 novel by David Brin. In it, we are introduced to a world where items, instead of wearing out, actually improve the more they’re used. For example, characters need only one set of clothes, as the more often clothes are worn, the better they fit and the more comfortable they become. This has interesting social implications: wealthy characters have to hire people to wear their extra clothes; otherwise their finery will just decay in the closet.
At one point in the novel, the characters need, basically, an airplane. So they strap together some sticks, hop on their contraption, and push it off a cliff. As long as their craft survives the fall (and doesn’t kill them), then that’s good enough. It will improve over time. They go off the cliff again and again until they have a working plane.
As the maintainer of a large open source project, I have seen this “practice effect” in action a number of times. Someone creates a feature they feel is needed, but the first version often does little more than the bare minimum to satisfy the requirements of the user. If the feature has limited appeal, that may be the end of it. But if it has broader applications, it won't be long until someone else steps in and makes an incremental (or greater) improvement.
That improvement draws in still more people, and, before you know it, the code is more powerful and more robust than anyone imagined. It may also have wandered off in a direction completely different from what the original contributor intended. Instead of a Piper Cub you end up with F-15.
From a business standpoint, the practice effect has a number of consequences.
First, there is money to be made in managing the chaos that can result from numerous changes made to software. Companies such as Red Hat and Canonical put out specific combinations of software and then, often for a fee, administer any changes to it. There is value in this work, and people are willing to pay for it. If you run a business around open source, be thinking about ways you can help your customers control the chaos that comes with change.
Second, you can apply the practice effect to the way you manage projects. To use a baseball analogy, in traditional software development the idea is to score by hitting a home run--one big project that pays off big. But it is also possible to score by hitting singles, and it is often easier to hit several singles than one home run. The beauty of hitting singles--i.e., dividing projects up into smaller pieces--is that objectives change, and, as a project evolves, the end users (your customers) may change their minds about what they want to accomplish. They may even see new possibilities that guide you to create something totally different from your original idea.
Finally, don't be afraid to employ the practice effect with your business plan. If you have a great idea for a new product, try it out. Don't over-analyze it. The second part of esr's statement is "listen to your customers." What you think they want and what they actually want can be different, and structuring your business so that you can rapidly adapt to better meet their needs will take you a long way down the path to success.
The open source way is based on iteration, practice, and play. The quickest way to success is to try out new ideas and products--get them out into the marketplace--knowing that (most likely) some will fail. Discard the failures quickly and unemotionally, and then move on. The sooner you figure out what ideas don’t work, the more time you’ll have to focus on the ones that do.
Comments are closed.