Can Web 2.0 Evolve Into an Enterprise Technology? - SaaS - Network Computing
Hathaway started using wikis four years ago to manage the IT department’s internal documentation, but soon saw that the same technology could be more widely applicable. “The work itself was becoming more collaborative, but the tools had not.” In 2005, he decided to roll out TWiki, a popular enterprise wiki whose other users include Disney, Yahoo and British Telecom.

It was a decision Hathaway came to regret in fairly short order.

The problem was that TWiki couldn’t easily share data with Alfresco, the bank’s open-source CMS. Users who needed information had to look in both, while those adding documents risked duplicating effort. The bank didn’t want to give up on either, so Hathaway turned instead to Deki Wiki, which is also open-source but backed by a commercial vendor, MindTouch. Its biggest advantage is that its Web services API eases integration with other applications.

“It means a Google map can show up on a Deki page, and we’re building an uber-search,” he says. “In my ideal setup, Deki would be a front-end to Alfresco.” The API also lets the wiki use the bank’s existing security architecture to limit user access to specific pages, important for preserving the Chinese wall between analysis and sales.

According to Hathaway, the wiki is now providing a real ROI.

Unlike other single-use or personal use wikis, the Deki Wiki platform, is delivering real ROI to the enterprise. The use case Hathaway outlines is becoming increasingly more common. Deki Wiki is being used as an interface to other applications, most commonly legacy, or as an aggregation point for multiple databases and applications. Deki Wiki’s ability to mashup, adherence to standards (no data lock-in), and complete API, is delivering real value to the enterprise not evidenced by other wiki applications.

Andy Dornan, the author of this piece, also provides some coverage of QEDWiki, describing it as a mashup platform. I’m not certain he realized he was also describing Deki Wiki. The difference between QED and Deki Wiki is that Deki Wiki is: more usable, more easily extended (REST vs. SOAP), has a more robust API, is open source, has a larger and more active community, has a larger install base and a higher rate of adoption.

Hathaway addresses a very important point in this article. Deki Wiki can provide a bridge to multiple applications and data stores. All other wikis are creating just another independent data silo that has to be managed and mined. These wiki data silos will eventually become a problem because the data is stored in a non-standard and non-reusable format (wikitext) and, most often, there is no enterprise search tool to mine it with. Choose wisely when selecting your wiki. Any discerning evaluator will conclude: Deki Wiki is the only appropriate choice.

MindTouch’s Deki Wiki is powering the official wiki for BlogWorld Expo, the world’s largest blog show, at Las Vegas on Nov. 8-9. Deki Wiki was selected because of its intuitive user interface, easy integration and customization that allowed it to be blended with the main site seamlessly and quickly. Working with the show’s organizers, MindTouch is offering cool prizes (iPod Shuffles and gift cards) for a contest to submit fun and satirical wikipages. The categories include best spoofs on a MySpace page and Celebrity Fan page (think Paris, Lindsay, Britney). All participants will also receive a free Pro account on the soon-to-be upgraded www.wik.is, a hosted wiki service for prosumers, groups and SMBs. Come to the show; blog about it. Come to the site to be wikified.

Mindtouch rising in the open-source wiki market | The Open Road - The Business and Politics of Open Source by Matt Asay - CNET Blogs
One of the great things about open source is that it provides a very tangible way to measure interest in a product: downloads.

Matt Asay, who writes for C|Net blogs just discovered the fact that MindTouch Deki Wiki is the world’s most popular commercially supported wiki. Thanks for the nod Matt.

Matt goes on to state:

Ambitious. Dethroning mediawiki is like taking on Linux if you’re Solaris. Possible, but an uphill battle. Still, it makes for an interesting market.

However, this analogy is not appropriate. Open Solaris has a long way to go to becoming the polished product Linux is. I went to an Open Solaris event a month ago at Sun. Ugh, the guy talked for 45 minutes about their new installer. You see, Deki Wiki is a far more polished and powerful product than Mediawiki. Deki Wiki just makes more sense. Ease of use, feature set, data re-usability, API. Deki Wiki wins hands down. I think a more appropriate analogy is: this is like Toyota taking on Ford in the 70’s.

Aaron, our cofounder and chief energizer extraordinnaire, quickly put together a stylwiki on the worst fires in Southern Californian history during his vacation! While it is rough with a little bit of content containing resource links, interactive maps, pictures, Twitter messages, videos and comments from various sources, his effort has already drawn national attention in the form of blogs from the New York Times and Center for Citizen Media. As many others have observed, a wiki is the perfect repository for comprehensive and current information relating to a topic so users can come to a central place and contribute, collaborate, share and access content. It’s too bad we didn’t have this ready when the fires struck. But it’s not too late.

We are inviting Web-savvy volunteers, public officials or private firms involved in all aspects of public safety and emergencies to contribute and organize the content so they are easily found and consumed by the public to help them, find support in each other, and share their experiences which they would never forget. It’s as easy as signing on to the site. We will provide the technology and support. In time, we hope we can turn this site into a comprehensive resource for preventing, fighting and surviving a disaster. Please contact us at support@mindtouch.com or just go to the wiki and start contributing.

I’m deeply saddened by the Southern California fires. Things have been crazy in San Diego County all week. Ken was evacuated as were many of MindTouch’s close friends and family. Most of us at MindTouch live right downtown so most of us have not been, thankfully, in harms way. Fortunately for my immediate family we’ve been out of town all week. In fact, we didn’t even know of the fires until a couple days into this tragedy. MindTouch, and I personally, wish the best to all of you in SoCal suffering from evacuation, or worse. Today was the first day I’ve had an Internet connection other than my phone and I just finished quickly throwing together this wiki page as a resource for the San Diego and Southern California fires. I hope it helps some folks. It’s aggregating a bunch feeds, vids, photos, maps mashups, etc in one central location and should provide a fairly comprehensive resource. Feel free to add to it. Nate Ritter and others have put many technologies into action to help out. I’m basically just pulling in their work. Thanks Nate, KPBS, the Governor’s office, and others. Best of luck to everyone.

A new investing community site is using MindTouch Deki Wiki to enable members to connect on a social network, collaborate on stock research, exchange investment strategies, find and interact with others with similar portfolio holdings, access and contribute to a financial encyclopedia, and educate themselves. Deki Wiki is currently powering the financial encyclopedia and collaborative stock research components, where there are approximately 10,000 pages of content already, with 2,000 financial terms and 5,500 pages of company research.

Deki Wiki was chosen because “we had a specific set of features to meet our needs: we wanted one that was PHP based, used MySQL, was free, had page permissions, had a WYSIWYG interface, and allowed us to customize. In the end, MindTouch Deki Wiki was the only wiki that had everything we were looking for”, said Gary Lucido, a founder of the site. The site will be upgrading to the latest version of Deki Wiki to further exploit its powerful content aggregation and mashup capabilities.

Last week, Aaron and I spent some quality time with Scoble. This is a short, fun interview where we cover some known ground, hint at things to come, and subtly poke fun at the competition. Hope you enjoy it too!

Aaron also gave a demo of Deki Wiki afterwards. It’s about 10 minutes long.

Monday 22nd, Amazon will be hosting the The Start-Up Project here in San Diego. The event will be held at the Stingaree and goes from 2pm to 5pm, followed by cocktails and networking.

Here are the details from Amazon’s website:

Who should attend:

• Entrepreneurs, founders and leaders of start-up/early-stage companies, and venture capitalists

Reasons to attend:

• Understand how to integrate Amazon Web Services into your business
• Find ways to cut fixed infrastructure costs while increasing reliability and scalability
• Hear what VCs look for when investing in early stage companies
• Learn from successful start-ups about their use of Amazon Web Services
• Network with local VCs and start-ups from your area

What:

• 2-5pm Presentations on Amazon Web Services, how to attract VCs, and how successful start-ups have built their business using AWS’ solutions
• 5-7pm Networking/Cocktail Reception

I’ll be presenting on Deki Wiki and our integration with Amazon S3. Should be a lot of fun!

Here is a selected group of open source projects from SourceForge.net.  The graphs on the right are pulled live from SourceForge.  If they don’t show up, the statistics server might be down.  Just check back later.  It usually recovers pretty fast.

Why am I posting this?  Well, we love the traction that we have received in the past few months.  We’re on track to reach 20,000 downloads per months for October.  To put this into context, we only reached 10,000 downloads of Deki Wiki in June 2007 since launching in July 2006.  In other words, we’re now achieving every two weeks what it took us almost a year to achieve in the first place.  Wow, that’s pretty nice!

But I say we can do better!  And to do so, we have to compare ourselves to those who are ahead of us.  For the longest time, we’ve been keeping an eye on Socialtext since they come closest as a commercial open source wiki provider.  However, we have outgrown, outrun, and out-competed them into the ground.  There is no point in continuing to compare ourselves to them: it’s of no value to us and it’s not fair to them.

Hence, the question is who do we need to compare to?  That’s where the below graphs come into play.

Socialtext Open Open source enterprise wiki application written in Perl September downloads: 582
MindTouch Deki Wiki Open source wiki platform written in C# and PHP September downloads: 17,659
Zimbra Email & collaboration server written in Java September downloads: 19,552 Recently acquired by Yahoo! for ~$320M.
Alfresco Content management system written in Java September downloads: 54,744
DotNetNuke ASP.NET content management system written in Visual Basic .NET September downloads: 131,584

Missing from this list are some notable other open source wikis, for which no public numbers are available.  According to Gartner, Twiki (Perl) has about 10,000 downloads per months.  But, there is no source for MediaWiki (PHP) downloads, but if I had to guess, I would say they must be achieving around 200,000 per month.

Ok, so where does this leave us? Currently, we perform at Zimbra level.  Next we will need to reach Alfresco level.  But ultimately, we want to dethrone the reigning champion: mediawiki.  Unfortunately, it appears that there is no other wiki competitor between us and mediawiki.  And since mediawiki is not commercially supported, well, that makes Deki Wiki already the #1 commercially-supported open-source wiki.  But I can’t be happy with that.  I want MindTouch to become the number #1 wiki, period.

In previous posts (here and here) I introduced the building blocks for asynchronous programming in MindTouch Dream, our REST web-services framework for .NET and Mono. Now it’s time to dive into the Result and Result<T> classes, which are the cornerstones of our asynchronous programming model.

Example Setup

First, let’s begin by creating a new Result instance:

Result result = new Result();

Second, let’s assume we have an asynchronous method called Write. In Dream, all asynchronous methods follow the same pattern: the last parameter is a Result instance, which is also the return value. For example, our Write method might look as follows:

Result Write(string data, Result result)

Third, let’s invoke our Write method with our Result instance:

Write("hello", result);

Ok, now we’re just missing is the ability to synchronize with the Write operation. The Result instance offers two methods to accomplish this: Wait and WhenDone.

Wait()

Let’s look at the first alternative using Wait:

Write("hellow", result).Wait();

This code will block until Write completes. If an exception was thrown, it will be rethrown by Wait. In other words, this invocation acts like a synchronous call. This is why the Result instance is returned: to enable call chaining. Furthermore, since it’s so easy to get synchronous behavior from asynchronous methods, library programmers don’t need to provide both variants. Also this form of synchronous invocation benefits from the built-in timeout mechanism. In short, it just made life a lot easier on both sides of the equation!

WhenDone()

The second alternative uses WhenDone:

Write(myData, result.WhenDone(delegate() {
    result.Confirm();
    ...
}));

- or -

Write(myData, result).WhenDone(delegate() {
    result.Confirm();
    ...
});

This code will not block Instead the continuation will be invoked when the operation completes. Inside the continuation, we call Confirm to rethrow any exception that might have occurred during the asynchronous call. Both uses are virtually identical aside from these differences:

1. The timeout timer associated with the Result instance starts ticking when WhenDone is invoked. In the first case, this occurs before Write is called, whereas in the second case it occurs afterwards. This means that whatever time Write took to setup its asynchronous operation will be counted towards the timeout in the first case, but not the second.
2. Two things must happen for the continuation to trigger: the continuation must be registered and the operation must complete. Since in the first case we register the continuation upfront, it is possible that both the operation and the continuation complete before execution returns to the current context. This is not possible in the second case, since the continuation is only registered after the Write has returned.

These differences are minor and generally don’t matter. I only point them out for completeness. I use the second notation as I find it more readable.

Return() and Throw()

The Result class provides two methods for triggering the continuation: Return and Throw. As the names imply, Return indicates successful completion, while Throw indicates an error.

Let’s look at what our Write method might look like on the inside:

Result Write(string data, Result result) {
    new Thread(delegate() {
        try {
            ...
            result.Return();
        } catch(Exception e) {
            result.Throw(e);
        }
    }).Start();
    return result;
}

Using the Result class is straightforward, although there are some good practices to keep in mind. For instance, the first statement inside our thread is a try..catch block. This ensures that uncaught exceptions are forwarded to the continuation. Strictly speaking it’s not necessary to forward exceptions since the timeout of the continuation will kick in eventually, but this will cost valuable time and resources. (Note: if you find this tedious, don’t worry; In my next post, I will introduce helper methods that make it seamless)

Result<T>

So far we’ve looked at the Result class, which doesn’t return a value. In essence, it’s the embodiment of an asynchronous void operation. The Result<T> class has the same methods as the Result class, but it can also return a value. The returned value is available through the Wait method and the Value property.

For example, let’s revise our Write method as follows:

Result<bool> Write(string data, Result<bool> result)

Then our synchronous example would look like this:

bool success = Write("hello", result).Wait();

And our asynchronous example would be:

Write("hello", result).WhenDone(delegate() {
    bool success = result.Value;
    ...
});

Also note that we don’t need to call Confirm anymore. The Value property does this check implicitly.

Caution!

If you call WhenDone or Wait more than once, you will receive an exception. Ditto for calling Return and Throw. The Result instance can only be used once to synchronize the completion and the continuation of an asynchronous operation. Similarly, accessing the Value property before the operation completes will also cause an exception to occur.

Summary

Wow, this post is a lot bigger than I was aiming for, but I felt it was important to capture the 99% use-case in one place. Next time, I’ll showcase methods from the static Async class which provides common asynchronous operations.