LWN.net Weekly Edition for August 16, 2012

GUADEC: New funding models for open source software

Money and free software have never been an easy fit. As Adam Dingle of Yorba explained at GUADEC 2012, the overwhelming majority of companies that produce free software underwrite its development with other income: services, contract work, support plans, and the like. But that dichotomy puzzled Dingle when viewed in light of the recent explosion of successful crowd-sourced funding stories on sites like Kickstarter. His talk asked why the Kickstarter approach is not working for open source — and what could be done about it.

Dingle founded Yorba in 2009, and his first hire was developer Jim Nelson. Nelson joined Dingle on stage to describe the project's background. Yorba is a small non-profit company best known for its GNOME applications, such as the photo organizer Shotwell and the email client Geary. But the group's non-profit status does not mean it is uninterested in paying developers; rather, it is attempting to fund development of its open source applications without subsidizing them with other work. So far, that dream has not been realized. Yorba does break even, but only by taking on contract work. It has a number of GTK+ projects it would like to pursue, but has had to put on hold simply for lack of time. The company is not looking for "Facebook money", Nelson said, just competitive salaries for its employees. "I think everyone in this room has had that dream at one point", he said, "to be able to be secure enough to write the apps they want to write".

Web donations don't work

But, asked Dingle, why is that so difficult? The issue is not unique to Yorba, he said, but a classic problem. Yorba has a donations page on its Web site, and it knows it has millions of users, but they do not translate into funding. "If every one of our users gave us one dollar once in their lifetime, we'd be fine". Dingle confessed that he had only rarely donated money on similar donation pages at other open source project sites, and a show of hands revealed that around half the GUADEC audience had done so at least once. On the other hand, Dingle said, he has given more money (and on more occasions) to Wikipedia — primarily "because Jimmy Wales asked me to, again and again" in Wikipedia fund-raising drives.

Clearly the Web donation page approach works for Wikipedia, which raised more than US $20 million last year, he said, but on the free desktop it is a lot more difficult. Part of the reason is exposure of users to the campaign. Wikipedia promotes its fundraising drives on the site. Projects, however, do not want to put advertisements in their applications, but only a tiny fraction of an application's users ever see the project's site, because they install and update the application through their distribution's package management system instead.

There are other difficulties with the donation model, Dingle said. Donation pages are difficult to use because making online payments is not simple, usually requiring a third-party service like Paypal that adds complexity. The offline alternatives (like mailing in a check) can be worse. In either case, it is far harder than clicking the "buy" button in Apple's self-contained iOS application marketplace. Static "donate" buttons also make it difficult to see how one's individual contribution affects the software itself.

A few people have tried to streamline the online donation process, he said, including Flattr. But although Flattr is helpful, Dingle said, "I don't know of any open source project sustaining itself via Flattr — or via donations, period." Even as open source has continued its struggle with funding, he said, a couple of radical new funding methods have exploded on the Internet in other fields. They are not really being used for open source, he said, but perhaps they could be.

Pay as you like

The first new development in funding is the "pay what you want, including zero" approach, which Dingle described as post-funding. This is the approach taken by the Humble Bundle video game sales. The first major use of this model was in 2007, he said, when the band Radiohead released its album In Rainbows online, and allowed customers to pay any price they chose for it — including free.

The Humble Bundle approach is a little different, he explained. There is no "free" option, and Humble Bundle employs other tactics to try and increase the purchase price (such as promising to release games as open source if a target is hit, and providing add-ons if a buyer beats the current average price). But Humble Bundle is instructive for open source projects, because it demonstrates that Linux users are willing to pay for games (which has long been a point of debate in some circles).

The question for open source projects is how to harness this approach and apply it successfully to software development. Dingle identified a few key factors that distinguish the post-funding model from traditional donations. First, there is always a limited time window in which to make the purchase. Second, the post-funding drive works for a completed project, and one that cannot be downloaded outside the drive. In other words, you must pay something to get the work at all.

Both factors could prove difficult for ongoing software projects to emulate. The Ardour audio workstation tries something akin to post-funding on its site, he said; it suggests a $45 donation to download the application. But Ardour is also built for Mac OS X, where users often download applications from the Web; Linux applications still face the challenge of requesting donations through a package manager. Dingle suggested that GUI package managers could support donations from within the application, but there are social and logistical problems. First, there is no automatic way to send donated funds to the application in question, so it would entail a lot of manual oversight. Second, there will always be people in the community who argue that "we should never ever suggest paying money for free software". In closing, he observed that there was a proposal to add a donation mechanism to Ubuntu's Software Center, but that it seems to have no momentum at the present.

Crowdfunding

The other new funding method to make a splash in recent years is crowdfunding, in which donations are pledged before work begins, which Dingle called a pre-funding model in contrast with the post-funding model. Kickstarter is the darling of the crowdfunding world, he said, although there are other players. On Kickstarter, anyone can propose a project, but Kickstarter selectively vets the proposals before accepting them. Once accepted, each campaign has a fixed time limit, a target price, and the money is rewarded in an all-or-nothing fashion at the end of the campaign. Kickstarter also requires projects to offer "rewards" for each funding level, he observed, although there are no real criteria in place governing them. He mentioned the OpenTripPlanner project, which offered a free copy of the application to the lowest tier of donors — even though the application is open source.

Kickstarter has other peculiarities worth watching out for, he said. Projects that are selected for heavy promotion by the Kickstarter team tend to get drastically better results, and the dollar amounts pledged are still rising. He pointed out that nine of the top ten highest-funded projects on Kickstarter's history have been in the first half of 2012. But Kickstarter also cannot force a project to complete the work it has pledged to do. The money is awarded in a lump sum, and completion of the project is based on trust.

Despite a handful of standouts (such as Diaspora), Dingle said that Kickstarter has not been a great match for open source projects, for several reasons. First, the site is slanted towards art and design projects; all non-game software projects get dumped in the general "technology" category, where they compete for attention "with all the helicopters, robots, and other things." More importantly, Kickstarter is geared toward getting a new project off the ground, not for developing the next version of an existing project that has existed for years. Finally, Kickstarter's selective acceptance means it is difficult to make the cut, requiring slick sales pitches, and facing increasing competition.

Others have attempted to build a "Kickstarter for software" before, Dingle said, including Fundry and CofundOS. Neither has achieved much success; Fundry is defunct, and CofundOS currently has five projects tagged with "GTK" — all from 2007. He then listed several reasons why Kickstarter has proven successful while the software-centric sites have not. First, the artistic and non-software projects are "cooler", so they attract more users and build a larger community around the site. Second, Kickstarter's time-limited and all-or-nothing funding creates a sense of excitement around each campaign, while the software sites function more like standing bounties. Third, the software funding sites always included complicated weighted-voting schemes through which the donors determined whether or not a feature had been completed enough to collect the pledged money. That made the process slower and more difficult to understand.

Moving forward

Dingle cautioned that "I don't have an easy answer", but concluded his talk suggesting that maybe it was time for a new crowdfunding site for software that built on the lessons from Kickstarter's success and the other sites' failures. Yorba has been discussing the idea, he said. Ideally it would be simple and good-looking like Kickstarter, but scoped only for software (and perhaps just for open source software). Launching it would probably require "bootstrapping" the site with several high-profile projects.

On the other hand, he said, such a site would need to take a different approach in some ways to fit open source projects' needs. One interesting idea would be allow projects to maintain an indefinite presence on the site, but still run separate, time-limited campaigns for specific development cycles. Or perhaps projects could run campaigns to back specific features, where each development cycle's campaign would determine what gets worked on for that cycle. Whether such a campaign would let donors back specific features, or let developers set "goal" features at different levels is an open question. It is also unclear how to support libraries on such a site: it is hard enough to fund applications, he said, much less supporting libraries that the users might not even realize are there.

Several in the audience had questions in the waning minutes of the session. One asked how a software crowdfunding site could generate the same excitement over novel and crazy projects, which are a big part of Kickstarter's draw. Dingle responded that the site would have to emphasize features. Another audience member observed that Kickstarter projects maintain a lot of buzz through ongoing interaction with the project teams, and asked how a software crowdsourcing site could do the same. Dingle agreed, noting that he had donated to a game project and received a near constant stream of updates and feedback, something that is hard for a small software shop to do, since writing updates means temporarily stopping work on the code. On that question, Nelson also weighed in, saying

Of course, none of Dingle and Nelson's observations about crowdfunding and pay-as-you-like finances are limited to the GNOME project itself. All open source software faces the same challenges when it comes to raising the money to keep developers at the keyboard. In recent years, Linux distributors have underwritten the development of desktop software through the sale of enterprise services and support contracts of various forms. Users have grown accustomed to that situation, and there is certainly nothing wrong with it, but Dingle and his colleagues at Yorba have shown that no one needs to accept that as the only viable funding model.

[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC.]

Comments (36 posted)

GUADEC: porting GNOME to Android

Rightly or wrongly, GNOME is regarded by many casual users as "a Linux desktop environment." It also runs on various BSD and Solaris flavors, of course, and there has been considerable discussion recently of developing a "GNOME OS" deliverable suitable for tablets and other devices. But at GUADEC 2012, there was yet another spin on the redefinition of GNOME: porting several underlying GNOME frameworks to Android.

A team of developers from Collabora hosted the relevant session, which was titled D-Bus, PulseAudio, GStreamer and Telepathy In the Palm of your Hand. Reynaldo Verdejo Pinochet acted as ringmaster for the other speakers, and provided an introduction to the overall effort. As many others have observed, GNOME and other open source projects are facing a "form-factor challenge", he said. Desktop approaches to user interfaces do not work as well on small-screen devices, and mobile device users exhibit different usage patterns: rapidly interleaving multiple tasks rather than camping out in one application.

The open source developer community is currently failing to provide a bridge from the desktop to mobile devices, he said. Meanwhile, the system-on-chip vendors are turning their full attention to Android — a platform into whose development the community has no say. Collabora's solution, he said, is not to "fix" Android or to "fix" the users, but instead to enable the GNOME project's technology to run on Android. As a result, developers and users will have more choice, and the GNOME components will continue to be relevant to both.

The bulk of the session was then taken up by a series of short status updates from Collabora developers working on "smallifying" frameworks used by GNOME applications. Covered were Android ports of PulseAudio, Wayland, Telepathy, and GStreamer. Despite the title, D-Bus was not discussed separately in the talk; Verdejo said in an email that the D-Bus port was undertaken as part of the Telepathy effort. Verdejo closed out the session with general information for application developers looking to port GNOME applications to Android.

Porting stories

Arun Raghavan spoke first, explaining the PulseAudio port for Android. Android's native audio subsystem is called AudioFlinger (AF). It is a software mixer like PulseAudio, he explained, but it pales in comparison to PulseAudio for features. "It's not as nice as PulseAudio, and you can look at code if you don't believe me." In particular, PulseAudio provides flexible audio routing (including network routing), dynamically-adjustable latency (which prevents glitches, saves power, and simplifies the work required from applications), and support for passing compressed audio (in contrast to AF, which provides only PCM audio transport).

Although the project's original goal was to install PulseAudio in parallel with AF, Raghavan said, that quickly proved impossible due to how integrated AF is into Android. So instead, Raghavan focused on building and installing PulseAudio as a complete replacement for AF, using the Galaxy Nexus phone as the target platform. First, he successfully compiled PulseAudio and got it to run and play sound on the Galaxy Nexus. He then started work on using PulseAudio to emulate AF's playback API "AudioTrack," a task that he said is almost complete. Still in progress is emulation of AF's policy framework (which controls volume settings, when playback is allowed, and so forth). After that, the next item on the to-do list is "AudioRecord," the AF audio capture API.

Next, Daniel Stone presented the Wayland port. Once again, the goal was to offer Wayland as an alternative to a built-in Android service — in this case, SurfaceFlinger. SurfaceFlinger provides buffer transport functions analogous to Wayland, and composition functions like those of Wayland's reference compositor Weston. Collabora's port is mostly complete, and is currently able to run Wayland demos. Still in progress is integrating Wayland into the Android stack so that it can run side-by-side with SurfaceFlinger, a challenge that includes both running Wayland and SurfaceFlinger applications at once, and handling clipboard events, task switching, and other functions. Still to come is styling, which would make Wayland applications seamlessly match the SurfaceFlinger look.

The Wayland work ran into the usual porting problems, he said, but there were special difficulties as well. First, Wayland relies on several kernel features too new to be found in the Android kernel (such as timerfd and signalfd). Second, the Android graphics drivers are "terrible" at buffer management in comparison to the desktop. Whereas Mesa provides full EGLImage sharing through the Direct Rendering Manager (DRM) and seamless zero-copy transfers (which Wayland can take advantage of through the wl_drm extension), EGLImage is an "absolute crapshoot" on Android. The quality of the implementation varies drastically between hardware vendors, and the graphics drivers are almost always closed.

Alvaro Soliverez presented the port of the Telepathy communication framework. Telepathy is modular, supporting a long list of pluggable back-ends (from XMPP to SIP, to proprietary networks like MSN) and bindings for a number of programming languages and toolkits. Soliverez's port picked the subset most useful for Android: the Gabble XMPP module, link-local XMPP with Salut (using Avahi service discovery), and Java bindings.

The port is fully functional, he said, and the patches have been sent upstream to Telepathy. Android users can download and install the Telepathy service as a stand-alone application. In addition to the protocols mentioned above, the account management and status management functionality works, and the GLib bindings are in place for developers. Ports of the rest of the framework are underway, he said, although assistance would be welcome.

Verdejo discussed the GStreamer port. GStreamer is already successfully in use on other platforms, where it can serve as a bridge to the operating system's native multimedia framework (such as QuickTime on Mac OS X or DirectShow on Windows). The GStreamer Android port is intended to be a complete port of the framework, putting Android on par with the other platforms. This required the development of two new elements to interface to Android's media layer: GSTSurfaceFlingerSink and GSTAudioFlingerSink. These are sink elements, which allow applications' GStreamer pipelines to play their output on Android.

But the Android platform "is crippled on purpose", he said, offering no real native development story. Instead, all of the emphasis is placed on writing Dalvik applications. Consequently, Collabora decided to build GStreamer as a system-level service as well. It developed two other elements, GSTPlayer and GSTMetaDataRetriver, which can function as replacements for Android's built-in media playback functionality. Up next are new elements to handle direct multimedia output over OpenGL ES and OpenSL ES, and capture elements for camera and microphone input. The OpenGL ES and OpenSL ES elements will eventually replace the existing Android GStreamer sinks so that GStreamer pipelines will not need to depend on the Android API layer. All of the GStreamer work is being pushed upstream and will be included in the GStreamer SDK.

Developing applications

Verdejo Raghavan closed out the session with general advice for other developers interested in porting their software to Android. There are two general approaches to consider, he said: the native development kit (NDK) and the complete system-integration route. The NDK is Google's official offering, and it places some requirements on the developer — specifically, all of the application's functionality must be in libraries, which are then accessed by Java code using JNI. The libraries must also be bundled with applications.

The alternative route is to develop the software integrated into the Android source, which means it must subsequently be distributed as a custom Android build. The system integration route does allow one to make the software functionality available to the entire platform, he said, rather than just to specific applications (which is a limitation of bundling the library with an NDK application).

Whichever route one chooses, he said, there are "gotchas" to look out for. Android exhibits not-invented-here (NIH) syndrome, he said, right down to the basic C library: it uses Bionic, a "bastardized" version of libc with missing APIs and hobbled features. Android also uses unique Git repository and patch management tools written by Google, he added. But the main sticking point is Android's specialized build system, which relies on Android-specific makefiles. Maintaining those alongside the makefiles needed for another platform can be a considerable headache.

To simplify the process, Collabora created a tool called Androgenizer. Developers need to set up only a single top-level Android.mk file for the project and Android target rules in Makefile.am. The target rules call Androgenizer, which generates the makefiles Android expects (using Google's macros and Android-specific variables). Androgenizer can be used to generate makefiles appropriate for either NDK or system-integration Android builds, by checking for an environment variable called ANDROGENIZER_NDK.

The Androgenizer tool does not make building for Android trivial, he said, but once you figure it out, it only takes about 30 minutes for each new project. Although the process is not hard, Verdejo encouraged anyone working on an Android port to get in touch, saying the company is interested in helping.

All things considered, the ports of these and other frameworks from desktop GNOME (there are several other projects on display at the company's Git repository) offer an interesting take on the desktop-versus-mobile "problem." Typically the massive increase in mobile Internet devices is talked about as a sign that desktop projects are doomed; Collabora's GNOME-to-Android ports show that developers do not need to take that as a foregone conclusion, even for a tightly-controlled platform like Android.

[The author would like to thank the GNOME Foundation for travel assistance to A Coruña for GUADEC.]

Comments (13 posted)

The GNOME project at 15

On August 15, 1997, Miguel de Icaza announced the launch of the GNOME project. In the following years, GNOME has seen more than its share of ups and downs; it must be considered one of the community's most successful and most controversial projects. This is a moderately significant anniversary, so it makes some sense to have a look at where GNOME came from and speculate on where the project may be heading.

In the mid 1990's, the Linux desktop experience was provided by such aesthetically striking components as the fvwm window manager, the Xaw toolkit, and the Midnight Commander file manager. That was more than enough for many early Linux users, quite a few of whom, having written their own custom modelines to get X working with their monitors, felt no need for a desktop system beyond what it took to get their xterm windows arranged nicely. Every community has its discontents, though. In this case, one of the first groups to get itself properly organized was the KDE project, which started hacking on an integrated desktop environment in 1996 and which, by the middle of 1997, had some interesting results to show.

The problem with KDE, of course, is that it relied on the Qt toolkit, and Qt was not, at that time, free software. This decision led to epic flame wars that put current squabbles (GNOME 3, or systemd, say) to shame; they just don't make flames like they used to. Some attempts were made to get Trolltech to change Qt to a free license, but Trolltech was not yet interested in considering such a move. It is interesting to speculate on what might have happened had Qt been relicensed in 1997 rather than three years later; one of the deepest divisions within the free software community might just have been avoided.

Then again, maybe not. We're not entirely happy without something to fight about, and Emacs-versus-vi, by virtue of predating Linux entirely, was old and boring even in 1997.

The stated goals of the newly-launched GNOME project were straightforward enough: "We want to develop a free and complete set of user friendly applications and desktop tools, similar to CDE and KDE but based entirely on free software". The project would be based on the GTK toolkit which, to that point, had only really been used with GIMP. The project also planned to make heavy use of the Scheme language — an objective that faded into the background fairly quickly.

GNOME itself remained very much in the foreground. Compared to KDE it had a different license (even after Qt was freed), a different implementation language (C vs. C++), and a different approach to the desktop — all fodder for plenty of heated discussions. Miguel was from early on an admirer of Microsoft's ways of doing software development and tried to push many of them into GNOME. Companies were formed around GNOME, including Helix Code/Ximian (eventually acquired by SUSE) and Eazel (which followed the classic dotcom trajectory of burning vast amounts of money before its abrupt death). There was clearly a lot of activity around GNOME from the very beginning.

The project produced three major releases: 1.0 in 1999, 2.0 in 2002, and 3.0 in 2011. The 2.0 release provoked a flood of criticism as the result of the project's focus on removing options whenever possible. A perceived arrogance on the developers' part (one described some user-requested window manager options as "crack-ridden bogosity") was not helpful. The GoneME fork was started in response, but did not get very far. Over time, enough features returned to the desktop, and things improved enough overall, that most users made their peace with it and stopped complaining.

The 3.0 release, instead, has provoked a flood of criticism as the result of the removal of options and features. A perceived arrogance on the developers' part has not helped the situation much. The MATE desktop fork has been started in response; it's too early to say just how far it will get. Meanwhile, a few features have found their way back into subsequent 3.x releases, and some users, at least, have made their peace with it and stopped complaining. Others, needless to say, have not.

Where to from here?

Fifteen years in, it would be hard to argue that GNOME has not been a success. The project is arguably the most successful Linux desktop available. It has an advanced code base, lots of developers, a well established foundation with a fair amount of corporate support, and more. There must be no end of free software projects that can only dream of the level of success that GNOME has achieved.

That said, there is a visible level of concern within the project. The relentless criticism of GNOME 3 has proved discouraging to many developers, and the millions of new users that GNOME 3 was supposed to attract have not yet shown themselves. Distributors are making noises about trying other desktops, and Ubuntu, arguably the highest-profile GNOME-based distribution, has gone off in its own direction with yet another fork. Meanwhile, the desktop in general looks like a shrinking target; the cool kids have gone elsewhere and GNOME seems to not be a part of it. In this situation, what's a project to do?

Allan Day's GNOME OS post shines some light on what at least some of the project's developers are thinking. Much of it looks like a continuation of GNOME's recent work — completing the GNOME 3 user experience for example. Some seems like basic sense: making the system easier to build and test would be near the top of list. Others are unsurprising, but may not get the results the project is after.

The post never uses these words, but the GNOME project clearly wants to put together yet another "app store" infrastructure wherein third parties can offer proprietary applications to users. For whatever reason, enabling proprietary applications has always been seen as the path to success; the whole point of the venerable Linux Standard Base exercise was to attract that kind of application. Making it easier to add applications to the system can only be a good thing, but it will not, on its own, cause either users or developers to flock to the platform.

GNOME also clearly plans to target tablets and handsets. Again, the objective makes sense: that is where a lot of the buzz — and the money — is to be found. The problem here is that this space is already crowded with free (or mostly-free) alternatives. Android dominates this area, of course; platforms like Tizen, Plasma Active, webOS, Firefox OS, and ChromeOS are also looking for users. It is far from clear that GNOME has something to offer that will make it stand out in this crowd, especially since Allan does not expect a "touch-compatible" version of GNOME 3 for another 18 months. As Eitan Isaacson put it recently:

He has an interesting counter-suggestion: GNOME, he says, should aim to be the platform of choice for content creators. There could be some potential here; this is not an area that large numbers of projects are targeting, and incumbents like Mac OS seem vulnerable. Where content creators lead, others will often follow. There are some obvious obstacles (codecs, for example), but this is a target that could possibly be reached.

Most likely, though, GNOME will continue its drive for mainstream success and those millions of new users. The project might just get there: it retains a solid code base, many talented developers, and a supporting ecosystem. One should never underestimate what a determined group of developers can accomplish when they set their minds to it. The rest of us should either support them or get out of the way and let them follow their path. Watch this space over the next fifteen years, and we'll all see what they are able to achieve.

Comments (207 posted)