In 2000, I was part of a team developing web applications. We favored open source software for the foundation of our web services, such as Apache and Linux, and widely used software such as BEA Weblogic, and the Java programming language.
Using these tools, when we ran into a problem, we could count on being able to Google the problem, and find an answer – usually within a few minutes. Sometimes the solution would be posted by another user like us who encountered the same problem and worked out a solution. On other occasions, the solution would be posted by someone from Weblogic or Apache, who would be monitoring public forums for problems posed by users, and would answer with the expertise of someone intimately familiar with the product. On the rare occasion when we couldn’t find an answer, one of us might post our problem to a relevant Usenet newsgroup. Within a few hours, we’d get a helpful response from someone else who ran into the same problem and figured out how to solve it.
Our team worked at web speeds, we were passionate and dedicated, and we loved our work. Being “in the flow” was a big part of it: you get going, you are productive, you feel productive, and it makes you even more productive.
Then, in 2001, for reasons quite unconnected to anything our little team was doing, our company forced all Java web application teams to move to a single proprietary J2EE platform. The support model changed to a typical enterprise support model. We funneled our support requests to a single support contact, they funneled our requests to the support team for the priorietary software, then the requests would get funneled to the right support or technical experience.
The pace of everything slowed dramatically. The questions we used to research and answer ourselves via a simple Google search in five minutes now took at least 24 hours to turn around. And the more technical stuff that we use to get answered via a Usenet newsgroup or web forum now could take a week or more before we got a response.
Meanwhile, productive work would grind to a halt. For engineers who were used to working on Internet time, and getting an answer commonly within 10 minutes, and in the worst case within several hours, this was the ultimate frustration. The team grew dissatisfied, productivity plummeted, and we were no longer “in the flow”. Even when their customer support finally did get around to answering our questions, no one else could benefit from it, because the problem and solution were never posted in a public forum.
The worst part of all this is that the “support” of the proprietary J2EE software was considered one of the benefits of using it by the management folks who made the decision to use it. But free, open support is far superior to paid, closed support. This is something that open source developers and users have known for years, and it is a big part of the reason why open source software has such a passionate and loyal following.
There are several lessons to take from this story:
  1. Knowledge capture and public sharing improves the support experience and decreases the work required by paid support staff.
  2. Customers inherently have a customer perspective on issues, which paid support staff lack.
  3. For a popular product, there are likely to be more customers available for helping other customers than there are support agents available.
  4. In most cases, the speed and access advantages associated with abundant information on the web far outweigh any minor benefit to be gained from one on one paid support.