The other side of the Open Company argument
The Open Company Test was pretty well received. Check out how JotSpot and XWiki rated themselves. If I have time, I may see how the other wiki-makers stack up. I imagine that they all do reasonably well — they're young companies, run by people who understand the power of collaboration.
But what about other companies: the staid, the entrenched, the enormous, the sclerotic? What about all those vendors who haven't seen the power of collaboration first hand and are too afraid or too bureaucratically immobilized to change?
Well, this post is for them. Instead of focusing on how openness can help us as users, I want to explain why being open is in the interest of a software vendor. I'll use the same criteria that I outlined in the original post, but I will argue from the other perspective.
- Open Sourcecode: The advantages of open source code are extremely well known. In the best cases, software developers can get an enormous amount of value from user-contributed code. But even if you are not willing to open you source code under an OSI license, giving a developer license to your customers is still a smart thing to do. It allows your users to fix problems or build custom solutions that are not economically feasible for you to develop yourself. Customers who might otherwise have chosen not to buy your application now have another option. Failing to provide that option only forces them to look elsewhere.
- Open Data: If users are going to trust their data to your application you have to be worthy of that trust. That means returning the customer’s data to them intact, in a useable format, without hassle, whenever they ask for it. This is (or should be) a fundamental business requirement.
- Open APIs: Offering open APIs to your application gives your customers more that many more ways to use your product. It allows them to build innovative, customized solutions that you don’t have the resources to pursue. You can meet more needs, make more sales, and deeply integrate your product into their computing environment, all without one-off, custom development on your part.
- Open Pricing: Open pricing is all about saving time: yours and your users’. Users get immediate answers to their questions, and your sales people don’t waste time chasing up leads that never had a chance of going anywhere. Pricing is often one of the very first things that a potential customer wants to find0 out. Hiding that information, making him go out of his way and delay his investigation to wait on your response, does nothing but frustrate your potential buyer.
- Open Bugtracking: Opening your bugtracker empowers your users to find answers to their own problems. It saves you time and effort. (See my earlier post for a real world example.) And an open bugtracker takes less management because because users enter fewer duplicates.
- Open Feature Voting: Allowing your users to vote on bugs and features gives them a voice and an investment in your application. It engages your customers in conversation with you. And it is a cheap, honest and reliable source of customer feedback. And it helps you set your priorities to match what your customers really want.
- Open Communication / Open Community: The arguments for open bugtracking also apply here: building a community around your software allows your customers to help themselves and to help each other, all with a lower tax on your internal resources. You can pull your customers into the broader user community. Make them experts on your products. Allow them to develop personal relationships with people inside your company. This will bind them more tightly to your application, make then happier using your software and make them more likely to recommend it to others.
- Open Documentation: Participatory documentation, again, lets users help each other, saving you work. And it’s a great source of feedback about your product. You can immediately see aspects of your product that are confusing or don’t work as planned.
- Open Customer Support: Open customer support wherever possible to avoid reinventing the wheel. Once you’ve found a problem in your application, and spent time to diagnose and fix it, make that information available to the rest of your users — without forcing them to call a designated customer support person. It’s cheaper for you and easier for them.
In summary, openness can allow a software company to leverage resources far beyond what they actually have. There is no software company on the planet — not even Microsoft — that has extra time on their hands. Your users are willing and able to help themselves, and each other, if you give them the tools. It will save you time in the long run — time that you can devote on making your product better.
But even more than that, engaging your users as valuable contributors will create more satisfied customers. Users who love your product because of it allows them to do more. Users who will give you honest feedback. Users you are emotionally invested in your application. Users who will give you the benefit of the doubt if you have to make unpopular decisions. Users who trust your company because you speak honestly and deal fairly with them. Users who become partners in the success of your product instead of just customers.
One Comment
Comments are closed.
Hey Jonathan.. Great summary of the advantages of openness..
Openness is a huge accelerator.. It is very hard and expensive to communicate about what you do and about your strength. Openness does allow this by showing many things in the open with a wider audience and accelerate the business. For example:
– blog about what you do and your business. This is less expensive than Press Releases and create more personalized contacts. It is also viral, as other bloggers can pick up what you say and relay it.
– open bugtracking also shows your response time in your support tool. Companies can view how serious you are. Indeed users can find their own problems and that can increase satisfaction and reduce support costs.
– for APIs, it is of course important that partners do what you can’t do, but it is even more important that partners make money when you are making money. Companies wanting to build an ecosystem need to integrate partners in that ecosystems. Companies that don’t do that well and/or don’t share revenue well with the partners will loose then or get a bad image. This can be very destructive these days at the speed at which information flows about your behavior. Screw one of your partners once and you might loose 100 potential partners. It is one of the seven rules of why Google will rule the world (http://www.infobaseventures.com/blog/2005/02/02.html#a289) according to Paul Allen’s analysis..
Concerning open-source, which is of course the major “openness” of XWiki, besides the contributions (it takes long to build this) and the bug-detecting and fixing (there is huge value here), Open-source allows branding since the software is highly used by early-adopters which I believe will less and less pay for software given the demand and the level of hackability that they are looking for. There early adopters create branding which brings you the clients that want service and support (a huge part of the business is support and service). From there the value I see for open-source (because you could just make a “free” version with an “source-code access” license) is the relationship with the client that changes. With open-source the client partly owns the application he is buying. He feels able to get away from the relationship with you in the case there is something going wrong. There is actually no reason he will want to do that, because he came to you for the services and support and the knowledge you have.
The risk of openness is giving information to your competitors or potential competitors.. But another type of “openness” is the “partnership openness”, which I would define about the willingness to do partnerships with any type of players in your market. For XWiki, I’m very responsive to potential partners and want to listen about how they see things and how they would like to approach the market. It can be double license, white label, reselling, a technlogy sale, revenu share. The idea is that you have a technology and a service. There are many ways people would like to experience this technology and service. You should be as open as possible (speed and focus is of course an issue here) to how your customers and partners want to experience it. Also very important is also speed now and the perception of who is the leader and innovator. You can get this from openness.