One Wiki, Best of Both Worlds

Back in November, Andy McAfee shared a great wiki case study from Avenue A | Razorfish.  They adapted MediaWiki to meet their needs.  Leveraging open source, a great approach for a company that builds custom Intranets.

But Jeff Walker of Atlassian Confluence, a commercial wiki vendor, disagrees:

It strikes me that if Razorfish invested all this effort and money, then the question needs to be asked: Is Mediawiki an enterprise wiki? Certainly not out of the box.

One full-time intern and two part-time developers is at least $50-100K for one year! Probably the latter number. Mediawiki in this instance became an enterprise wiki but only after considerable work.

To which Shiv Singh of Razorfish replies:

… Our wiki did not take a full year to build and the part-time developers were bench resources. In other words, it did not cost us $100,000 as Jeffery implied. Furthermore, enterprise 2.0  as coined by Andrew McFee is not about cost but about what the software does for its users and how they shape the software themselves.

Commercial enterprise 2.0 software like Socialtext, Brainkeeper and Atlassian Confluence are great options for some business scenarios and we often recommend them to our own clients. But in other cases, simply modifying open source sofware can get an organization what it needs. Furthermore, by modifying mediawiki we were able to get exactly what we needed. Most importantly, by virtue of how it is being used, we know that it is social software in an organization - and that's the most important part of an enterprise 2.0 solution.

Anu Gupta of Headshift attempted to comment (as did I and I'm stealing the structure of this post from Anu):

Shiv - not sure I agree with you…

I think you’re lucky (or unlucky) in having bench resource available - a lot of companies aren’t in that situation and have a constant battle to get developer time. So, faced with that situation - what is the cost of having 2 developers available, part time, to develop and look after your mediawiki instance over 18 months ?

Secondly, would spending the relatively small amount on an unlimited license for Confluence ($8,000) or Socialtext, and getting out of the box AD integration, search and granular permissioning, represent better value than developing it from scratch ?

Also, developing inhouse commits you to a codebase that with an audience of just yourselves (until you release it out to the community ?).

I can see both sides here.  Jeff's point is that MediaWiki wasn't designed for Intranet use out of the box.  I believe there is truth to this, that MediaWiki will always be optimal for running a public online encyclopedia or similar community.

But you can't slap down open source development on the basis of cost alone.  Going with a proprietary vendor inherently restricts freedom -- both through lock-in and the ability to extend. Open source enables a company to both manage risks, share risks across a community and adapt software for their situation.  Engaging internal developers also engages core stakeholders that can help wiki adoption.   

I also find the cost argument to be misleading. The closed option has a license cost, the open option has no license cost.  But the customer's customization requirements would have to be met somehow, and who knows how the buy vs. build works out in this case where pricing isn't transparent.

Anu's System Integrator perspective provides a third way, where a third party gains economies by providing solutions across a base of customers.  But to remove the question mark at the end of his comment, so does an open source community.  It seems Razorfish benefits from having the bulk of its codebase be community maintained, and I would suggest sharing their extensions are in their best interest. I'm not questioning the value of such integrators, each has their own proposition and value add, but the customer would be better off if an SI serviced codebase was, again, open source.

The fourth way involves me tooting my own horn.  If Razorfish started their project today, they could use Socialtext Open and get the best of both worlds.  The best of breed enterprise wiki and the freedom of open source. 

We chose a commercial open source business model because it strikes a balance between freedom and profit.  Not because we are hippies.  But because it is in the best value for end customers.  As first to market and first to feature, we continue to innovate and there is the chance that one day Razorfish would find having us service the software to be a valuable option.  But that is up to them.

When competing in a market full of choice, you have to be a choice leader.  Not just in providing on-site, Appliance, SaaS and open source deployment and licensing options.  But enabling your customers to make their own choices.

Comments

[Kin Lane]

Thanks Ross. I live this battle everyday, being historically a Microsoft Developer trying to deliver myself from my shackles. Your ending rings the truest for me:

"When competing in a market full of choice, you have to be a choice leader. Not just in providing on-site, Appliance, SaaS and open source deployment and licensing options. But enabling your customers to make their own choices."

[Shiv Singh]

Ross,

Thanks for your comments. They are thought provoking. Socialtext Open Source certainly wasn't an option for us at the time.

Sharing the code base with the broader community is definitely something that we're exploring. Modifying mediawiki itself served as a great learning experience for us and not just for the developers but also for the user experience designers and strategists involved in the project.

The comments functionality on the workplace blog are working properly now. It seemes that I had an overly energetic spam filter turned on.

Shiv

[Lee Bryant]

Shiv's case study is a great one, and we already have it in our use case library as an example of good practice. In fact, we have a few similar implementations inside large firms using a range of tools and platforms, and in the spirit of open sourcing our ideas we plan to release our use case library very soon.

But I have a problem with this idea that OSS = freedom. OSS is vitally important and we love it to bits, but It is freedom only for developers, not users. You imply criticism of Confluence for not being open source, but in fact they do provide source code to customers, and this is partly why they have such a large and productive developer community. You say that "going with a proprietary vendor inherently restricts freedom -- both through lock-in and the ability to extend," which can of course be true, but in the case of Confluence, it is not.

Open services, data and APIs (kudos to Socialtext for their investment in this, BTW) are more conducive to freedom than OSS, as they can at least be used by non-developers. But the freedom we are interested in is the freedom for normal people to do things they couldn't do before, ideally things that empower them and make their lives slightly easier, and it really doesn't matter which tool they use to get there. It is largely a practical, rather than ideological choice.

We love Mediawiki, and it is one of the very best wiki platforms for certain things, but as Jeff and Anu implied, it is hard to wrangle into an enterprise solution. That is not to say we ignore it. We have worked with it on one enterprise social software project and know of other large installs inside big firms we talk to. We also love Confluence and admire what you are doing with Socialtext. They are all good products, as far as I am concerned, and between them they are playing an important role in taking the wiki way inside the enterprise.

But for social tools and methods to gain traction inside large firms, we need to offer other modes participation as well, such as blogging, tagging, bookmarking, social networking, etc. combined into blended, situated systems that are designed to address concrete business objectives. We like this consulting-led model because we get the time and the headspace to take a holistic view of projects, and see them through to the end, rather than just make a sotware sale, ring a bell and move on, which is what the VC-funded software business model often requires.

[Ray Velez]

There's a couple of points I would like to add to this thread.

One thing is that a technology architect/developer is needed regardless of the solutions, whether saas, commercial in-house or open source in-house. Someone will need to invest time to install, configure, connect to active directory, etc. When a new version comes along or when active directory stops connecting after an upgrade are all examples of when a technologist is needed. There are lots of scenarios that require technology support.
The second piece which wasn't clear in the discussion I had with David was that the intern and part-time technologists supporting the wiki were also helping add content and format the wiki. Sometimes I would give the intern a directory full of documents that I was getting tired of sending around and ask them to upload. A time consuming activity regardless of which tool is being used. The intern would also help support people with activities such as, where do I click the edit tab, how do I rollback content, etc.
Lastly, a lot of the work invested was installing and configuring plug-ins. For example, we've added a plug-in that allows people to protect content. The nice part of working with a tool like mediawiki is that there are lots of plug-ins being added on a periodic basis.

[Neil Roberts]

Open Source is great, it's the reason we have half of this software in the first place but I think the motivation of open source projects are different from commercial ones. If you take dokuwiki or twiki for example and compare them to Confluence the feature list is very similar (http://www.wikimatrix.org/compare/MediaWiki+DokuWiki+TWiki+Confluence+Oddmuse)

Yet they are entirely different products, the implementation of confluence is much more focused toward the non-technical user, there is an attention to detail that I haven't yet seen in an open source competitor.

Yes, it comes at a price but the price is much smaller than the time it would take to get in-house developers to add the same level of mojo that is vital ease the path to mainstream adoption.

Not to mention that fact that taking a commercial product that can be installed and customised in days rather than weeks means my developers can work on other bespoke systems we can't get else where.

The technology choice is just the start, the real challenge is in working out how to get people to use it.