Wiki Resolved

As part of the continuing series of posts about my company's SDK Wiki, I've decided to lay out the arguments for and against it being publicly readable.

Those of you that followed the link above know which side ultimately got the better of the argument, but I think it's important to discuss the pros and cons of the decision. Our company is likely to see similar debates in the future, and if your employer is anything like mine, you're likely to experience them as well.

The Debate

The arguments for moving the SDK wiki to a login-only setup essentially boiled down to two concerns. First, that we were giving away our intellectual property. Second, that the information posted to the site could result in damage to the company's reputation or to litigation. Let's examine each objection.

The intellectual property argument was that one of our competitors could take the information on our SDK wiki and reverse engineer features of our product. In recent years, our industry niche, Enterprise Content Management, has seen serveral waves of mergers and consolidation, and the competition is quite fierce.

I suppose the hesitation is understandable, but the SDK Wiki was really more of an extended user manual than anything else. If a competitor wants to reverse engineer our product from a manual, well, good luck. It'll take them years. In the intervening time, I hope we'll have moved on to something better.

And as one senior executive pointed out, our competitors already have copies of our software and manuals. If they were serious about taking our product apart, they would have done so already. The only people we'd be protecting our IP from are our partners and customers -- legitimate users of our product.

What of the second point, that damaging information could be posted to the site? We'd already configured the SDK Wiki so that users have to log in to edit, so presumably no user can post information there that we hadn't approved. As for the content itself, we monitor changes regularly, so it's easy to fix if something goes wrong. So even though litigation or the potential of lost sales would be costly, it's not a very likely scenario.

On the other hand, what of the potential to increase customer loyalty through providing more and better information in a timely fashion? Or improving relations with our partners by making it easier to work with our product? Or helping to inform trade analysts? While these benefits are hard to quantify, they more than compensate for the risks, in my view.

Ah, the skeptics asked, why couldn't we couldn't simply provide all those people with a login? Why does the SDK Wiki have to be public to achieve those objectives?

Well, the main reason is that we don't really know who "all those people" are. We sell our product to large organizations, but we might not know who within those organizations uses the product. The same logic applies to our partners. We simply don't know which users need logins in advance.

We could allow them to sign themselves up, but as I mentioned in my previous wiki post, Internet search engines won't be able to index the content. Since many people use a search engine as their primary way to navigate the web, they might never find our site. Even if they do find the site, they won't know what sort of great stuff is posted there until after they sign up.

In the case of our partners, there's an additional incentive. These systems integrators, consultants and resellers often work with a variety of products. They already have a bewildering array of logins and passwords to manage. Most will opt out of signing up for yet another technology website, unless they're certain they need it.

Chances are, they'll look somewhere else for the information first.Perhaps they'll go to another website, one that we don't control, and who knows what they'll see there? At least if they come to our site, they can get the answers straight from the source. So it's potentially less damaging for us to make our content widely available.

The Decision

On balance, the arguments were strongly in favor of leaving the SDK Wiki publicly viewable. So after a month behind closed doors, the wiki has re-emerged with a stylish new look. We added a few disclaimers to highlight pages still under review and established a more formal monitoring process. I'm really happy with the final result.

And as frustrating as the ordeal was, it's made me appreciate two things. One is that this information management thing is hard, even for a company that does it for a living. I have a much better understanding of the work our customers go through to implement our ECM product now. I'll listen much more sympathetically to our customers as a result.

The other thing is that I work with really great people. It's been a challenge to deal with everything that's happening at our company lately. You can sense the frustration in a previous wiki post. But the folks at my company are awesome.

And I'm not just saying that because they let me win this one.