Sometimes I forget that not everybody is privy to discussion in our office regarding product decisions. Since our 1.8.3 release, we’ve incrementally added additional support for alternate WYSIWYG editors, FCKeditor and TinyMCE.

Jadus asked a salient question on our forums: “So far I haven’t really seen any dicussion on these forums as to why a switch from Xinha is necessary, or what value is provided by switching, and I’m interested in what is causing others to switch.”

I immediately went, “duh, nobody knows what you’re thinking; it’s probably a good idea to let the community know why you’re introducing such fundamental changes!”

A little historical (and by historical, I mean on a time-span of 2 years ;)) context about WYSIWYG and MindTouch is necessary to understand.

When we did our initial MediaWiki fork, the first engineering feat we tackled was WYSIWYG editing. Like many others, we felt that wiki markup was blocking widespread adoption of wikis inside enterprises. When we were looking at packages at the time, we picked (what was at that time) the best pick - Xinha. It had an active community, had a great feature-set at the time, and was open-source. Perfect!

The original direction of Deki Wiki was to focus exclusively on creating the best user experience, which meant that the WYSIWYG editor would become a key component of our application. So, we essentially forked Xinha and began a lot of custom development to handle our many special cases. This fork and custom development essentially froze us out of the ability to contribute back to the Xinha community (which I regret).

Over the past year, the product direction for Deki Wiki has shifted more towards integrating disparate information silos in Deki Wiki. When a powerful application like Deki Wiki has its home in a startup like MindTouch, the hardest engineering decision is usually in deciding what not to do. So a few months ago, we decided that our focus would no longer be in doing custom development on the WYSIWYG editor, but instead building off the community of an open-source WYSIWYG editor. So we cleaned up our Xinha codebase to synchronize back with with their product.

Unfortunately, in the months that we had forked off Xinha, the community had diminished in size. When we approached one of the project managers of Xinha to talk about upstreaming all our work back into their product, we realized neither side had the bandwidth to merge changes - not a huge loss, since most of our work was extending Xinha for custom features.

So I took a look around the landscape for suitable alternatives. We discovered that FCKeditor had matured into a nice project, and we saw adoption of TinyMCE increasing by other open-source packages.

The primary “feature” driving factor for switching editors was the rise of Webkit (Safari) and Opera (in Europe). Xinha supported neither browser, which was a total bummer. The rise of Safari should surprise nobody, considering Apple’s dominance over the past few years. Opera has a sizable following in Europe, and we’ve heard many requests from IT managers in Europe who want, very badly, to install Deki Wiki, but weren’t able to due to Opera limitations.

Going forward, we want to pick an open-source package which will continue to be maintained with bug fixes and feature improvements (undoubtedly IE8 will require a little elbow grease for WYSIWYG projects). We want to contribute upstream to these projects and not be the only beneficiaries of our bug fixes (we still do a little work on the editors). A large community and a wide vendor adoption is necessary for Deki Wiki, as we don’t want to deal with switching WYSIWYG editors.

But the benefits aren’t just for us: adoption of an existing open source package means that you get to take advantage of plug-ins developed by those WYSIWYG editors.

On the surface, this change seems very superficial (TinyMCE & FCKeditor seem pretty equivalent to Xinha), but this decision was made for the long-term: we can piggyback off an existing community for features and bug fixes to the WYSIWYG editor, which allows us to focus on what we do best in Deki Wiki.

categories: MindTouch