EtherPad source code is free, now what?

Google's newly-acquired startup AppJet released the source code to its popular EtherPad web editor recently, making good on a promise to EtherPad's users who were previously faced with a service shutdown following the acquisition. The source is under the Apache 2.0 license, which is GPL-compatible, making the code potentially useful to a wide array of free software projects. The release has the community debating the impact on similar and related software, and revisiting the contentious question of how free software in general can and should transition to the web-hosted environment.

Pad timing

EtherPad is a collaborative in-browser text editor. AppJet launched the product in the fall of 2008 with both commercial and free (limited to eight concurrent editors) versions, and it quickly gained popularity in the first half of 2009. When Google unveiled its own real-time collaboration system Wave in June, comparisons were inevitable. Many users found EtherPad's interface simpler to use and easier to understand, however, so it was no great surprise when Google announced that it had purchased AppJet and EtherPad on December 4. The AppJet engineers would work on Wave, ostensibly making it as easy to use as EtherPad itself.

What did come as a surprise to most EtherPad users was AppJet's announcement that due to the acquisition, it would be unceremoniously switching off the service for all users on April 1, 2010 — and to reinforce that the move was no April Fools' joke, no new documents could be created, effective immediately. There would also be no refunds to customers who had already paid for the "professional" service. The subsequent backlash from users and fans was forceful enough that, less than 24 hours later, AppJet CEO Aaron Iba posted a personal apology and announced a new "transition plan" — document creation would be re-enabled, EtherPad itself and the underlying AppJet Web Framework would both become open source projects, and AppJet would try to get Google Wave invites for EtherPad users.

Source at last

The source code release came on December 17, accompanied by the proclamation that AppJet's goal "is to let the world run their own etherpad servers so that the functionality can live on even after we shut down etherpad.com." The shutdown is still scheduled to take place on March 31, 2010, and new document creation may be again switched off sooner than that, if traffic is seen to "taper off." The source is hosted at Google Code, and includes instructions for compilation on Mac OS X and Linux. The actual code implements an EtherPad server running as a stand-alone HTTP server on port 9000. The server is written in Java and Scala, and requires MySQL. The client-side editor is implemented in JavaScript.

Some pieces of the service as it was provided at etherpad.com are not present in the open source release, however, notably file upload, document import/export, the email invitation system, and the framework for managing "professional" accounts. The file upload capability was provided by a proprietary servlet that AppJet could not include with the release; the other capabilities appear to have been left out for the sake of convenience. Perhaps those missing pieces, when taken with the news that the AppJet team still intended to shut down the service and not pursue further work on the code, contributed to those in the open source sphere describing the move as "dumping code over the wall" — a pejorative typically indicating the community's belief that the company has no interest in what happens next.

Source is still source, though

Nevertheless, the Etherpad release attracted many eyes and many comments from open source circles. Two topics dominated the conversation: what impact the EtherPad code would have on other projects, and how free software could protect users from suffering the inconveniences of a similar web service shutdown.

As it currently stands, the open source EtherPad code seems unlikely to develop as a viable project on its own. The Google Code site refers to the project as an "exhibition" and says that "we will try to support you in our spare time until we begin working full-time on Google Wave." There is an open mailing list, however, and several developers with non-Google IDs have been granted the Owner role. At least one independent public server has already been launched, PiratePad.net.

The other projects most likely to be affected by the availability of EtherPad source code are Google Wave (naturally) and other real-time collaborative editing tools like Gobby, AbiCollab (which we recently covered), and Bespin (also recently covered). Although Wave's document-sharing and editing capabilities are less mature than EtherPad's, it does have one notable advantage: federation is built in to the protocol, allowing editing sessions to be shared between multiple Wave servers, a feature EtherPad never had.

As for EtherPad's "threat" to other editors, the prevailing attitude is that in-browser editing trumps any desktop client editor because of the sheer ease-of-deployment, a feature that is critical to collaboration. On the other hand, Gobby's conflict-resolution algorithms are highly-regarded and well-documented (unlike EtherPad's), and the editor features niceties like syntax highlighting not found in the web editor. Gobby maintainer Armin Burgmeier commented on one blog discussion that the best way forward might be adding Gobby's concurrency control (via Gobby's libinfinity library) to an Etherpad-like web editor.

Branching out from pure editing alone, Red Hat's Máirín Duffy suggested that EtherPad's slick editing capabilities would be a good addition to some other web-based tools, MediaWiki in particular. MediaWiki is designed to encourage collaborative writing, after all, but it currently relies on HTML's "textarea" element and its own peculiar markup as an editing interface.

Web versus Desktop; collaboration versus solo work

However the EtherPad application evolves, the fiasco surrounding the shutdown announcement and subsequent code dump again raises the weighty and still unsolved problem of how free software ideals and practices should migrate from the desktop paradigm to the web service paradigm.

In her blog, the GNOME Foundation's Stormy Peters wrote that hosting free and open source web applications is fundamentally hard — open source web applications that thrive have always offered end users a hosted service (such as Wordpress.com or SugarCRM); those that have not tend to fail. There are varying business models, including advertising-supported free services, paid professional alternatives, and more, but unlike hosting a download site for desktop applications, there are ongoing support and labor costs that must be borne somehow. As long as the shepherding organization is a company that remains in business and actively involved, a hosted service is reasonably safe for users to rely on. The trouble arises when an acquisition, a change of business plan, economic woes, or other real-life events threaten the business itself. Consequently, Peters asked: Should software projects start non-profit foundations to provide web services?

Ubuntu's Jorge Castro opined in his own blog piece that existing free software groups such as GNOME and KDE ought to offer web services like EtherPad, just as they currently host mailing lists, revision control systems, IRC channels, and other collaboration tools. According to the post, Castro recently undertook a self-imposed experiment to use only web-based applications for a set period of time, just to see how the experience compared to desktop applications. He liked it so much, he has no plans to go back.

It is interesting to note, however, that the services Castro cites as examples are all communication tools: email, instant messaging, microblogging, and real-time note-taking at conferences. There are other web application use cases that do not inherently involve sharing data with other remote users, and as a result, might not inherently benefit from running solely on the web. Financial records, for example, might be convenient to access from multiple locations, but a hypothetical "Gnucash Online" service would not need to share information between users concurrently. Media players, to take an unrelated issue, are hamstrung by copyright holders' rights when online storage comes into play. Image, sound, and video editing, on the other hand, have low network latency requirements that make for a poor user experience under anything but the best network conditions — even if sharing the final product on the web is something the user intends to do.

Castro suggests that the myriad of free software groups provide hosting of web services for participating developers, not for the public at large, so it might not offer the protection-from-corporate-disappearance that Peters asked about. But for a collaborative editor like EtherPad, it might be just the thing.

Code drops are a gift to the open source software world and, as such, they are always welcome events, but rarely are they game-changers. EtherPad was a wildly popular product in its lifetime, but judging by the reaction to recent events, its popularity may have been more due to its implementation as a free web-based service than to ingenuity of the code itself. Thus, the bigger question going forward is one that free software has been struggling to answer for the past several years and will likely continue to struggle with for years to come: how can open source not just compete with closed-but-freely-accessible web services, but beat them on the critical question of protecting users from the catastrophe of being deserted by a service that disappears.