Succor for the Distraught, Support for the Deserted, Solutions for the Deprived Users of Abandoned OSS

If a tree falls in the forest and no one is there to hear it, does it make a sound?  If software does not benefit users, does it even matter?  Presently, users are facing a dilemma choosing between open source and proprietary software.  Although open source software (OSS) offers many benefits, it has been struggling with abandonment.  One study shows that, on average, 33% of all commercial software projects are abandoned, while nearly 67% of all OSS projects are abandoned (Bieman 290).  If OSS is to remain useful, if OSS is to have any significance, this high rate of failure must be addressed.  A solution must be found for the users of abandoned OSS.

In this paper, I will seek out a solution to the problem of abandoned OSS.  I will begin by defining “OSS” and “abandoned.”  Having wrestled those words into submission, I will analyze why OSS is often abandoned.  Specifically, I will look at how leadership and planning can cause OSS abandonment.  From that analysis, I will move to four potential solutions for the users of abandoned OSS.  I will conclude with the most promising solution: SaaS (software as a service).

The first term we have to tackle is “open source software.”  Broadly speaking, “open source software” is free software whose source code is distributed with the software, although many developers define OSS more narrowly.  The non-profit organization Open Source Initiative begins their definition by explicitly stating, “Open source doesn't just mean access to the source code” (“The Open Source Definition”).  Their definition lists qualifications for OSS such as free redistribution, free modification, and free use.  While the exact definition of open source software is an important issue for certification purposes, for the purposes of this discussion it will suffice to say that OSS is simply software whose code is freely distributed for editing, use, or redistribution.

With this definition established, we can explore the meaning of the word “abandoned.”  Generally speaking, abandoned software is software that needs attention from developers or administrators.  However, as I began working with OSS, I found that determining whether a given project qualifies as “abandoned” can be difficult.  Is software abandoned simply because developers are not issuing new releases?  Is software abandoned because no one offers user support anymore?  Is software abandoned if the developers take a hiatus from their work?  In their OSS research, University of Massachusetts Amherst professor Charles Schweik and his graduate assistant Robert English specify two types of abandonment: abandonment in initiation and abandonment in growth (11).  Schweik and English deem OSS projects “abandoned in initiation” if the developers have not released anything within a year of publicizing their project (11).  Many projects that have been abandoned in initiation can be found on sourceforge.net (“Top Apps”).  Projects on this site such as “EasyIt” and “EUGE” have not been updated since they were registered.  Schweik and English provide another guideline for labeling projects “abandoned in growth” if they showed promise initially but now have little download or development activity.

Even with their algorithm, Schweik and English confess that it is difficult to determine whether OSS projects have “failed” (10).  They note that some successful projects appear to have failed, when in reality they are quite successful.  They explain that some projects are designed for a limited audience and therefore are not downloaded frequently.  Thus the limited frequency of activity makes them look abandoned.  An example of OSS with a limited user group is a project called Moon Phases, which provides a dynamic moon phase calendar (Camp).  Even though this program has a small user group, it is still successful amongst its limited audience.  Schweik and English explain that other projects are designed for specific goals and are now “complete” (10).  Although these projects are no longer updated, they are still useful to many.  An example of completed OSS is a program for building websites called Views cycle (Crell).  While this project is officially “unsupported,” it still has over one thousand users. As we see from OSS with a small audience and completed OSS, some software that at first appears abandoned is quite successful.

While some projects reach a state of “completion,” others certainly do not.  This is not to say that incomplete projects are worthless.  Some projects are in a permanent state of development and improvement, yet they are still useful.  This summer I edited a website that was built with an OSS CMS (content management system) called Drupal.  While Drupal worked excellently for designing our site, it still required active developer involvement.  Because of the size, scope, and modular nature of Drupal, developers were (and still are) constantly adding features and fixing bugs, yet there is much to be done.  For instance, as I used Drupal, I struggled to find a module that would display video properly on our company’s site.  While some modules had been designed for video display, there was still room for improvement.  Another reason that Drupal was still “incomplete” could be found in its forums.  This summer I quickly discovered that the Drupal forums were the best place to get advice, and an essential tool for any Drupal developer.  The Drupal forums buzz with ideas, solutions, and basic support.  Were the community to have stopped all work on and around the project and abandon the forums, Drupal would become both outdated and excessively daunting to new users.  Hence we see that “abandonment” has a far more nuanced definition than simply “incomplete.”  Abandoned projects could be those that lack critical user support or those left with too many bugs to be useful.

Whereas some difficulties with using OSS can be solved with community support, other problems require faster and more reliable support.  Consider the following example.  This semester I am taking an English class that meets once a week face to face and once a week virtually.  To interact virtually, our class uses an open source electronic learning management system.  Because the OSS program did not work, we were not able to meet for our online class twice.  When issues like these arise, users need a new solution since they cannot rely on the tech support centers available through proprietary software purchases.  As we consider abandoned OSS we must look at all different kinds of unsupported projects, from the small project that recently dissolved to the ambitious project that fails to supply all of its users’ needs.

Having explored the meaning of abandoned open source software, we must next examine why software is abandoned.  If we examine what makes some projects successful, we may better understand why others fail or are abandoned.  In his seminal book The Cathedral and the Bazaar, OSS evangelist Eric Raymond explains several requirements for a successful open source project.  Raymond’s first requirement is that project leaders begin their project with a “plausible promise”; that is, they must write enough code so that the software runs and shows enough potential to attract developers (47).  In terms of abandonment, this plausible promise requirement means that projects launched without enough source code will likely be abandoned due to lack of support from other developers.  In terms of users however, OSS abandonment in the “idea” phase is not an issue, since users will not invest in a project that never truly begins.  In other words, if a project cannot gain traction with the development community, the project will not become attractive to users.

Raymond’s second requirement is that project leaders “be able to recognize good design ideas from others” (47).  As I worked with Drupal, I began to see how much OSS project managers simply synthesize and evaluate the work and ideas of others as projects become larger.  It would be practically impossible for Dries Buytaert, the leader of Drupal, to read about all of the modules that Drupal boasts, let alone modify their code.  While he certainly wrote most of the code when the project began, project leaders who do not wisely incorporate the work of others are on the road to failure.  As we apply this lesson to our study of abandoned OSS, we can see that poor management and poor teamwork can cause projects to be abandoned.

Raymond’s third requirement is that leaders keep software “robust and simple” rather than aim for creativity and originality (47).  Raymond argues that although leaders should recognize the quality work of others, they do not need to be especially creative or original developers themselves.  To support his claim, Raymond refers to his own successful open source project and Linux (the epitome of successful projects).  Raymond notes that both he and Linus Torvalds (the leader of Linux) were more successful because they did not attempt creative innovations in their source code, but kept their software “robust and simple” (47).  If leaders foster simple and durable software development, their projects are less likely to be abandoned.

Raymond’s final requirement is that an OSS leader must possess charisma (48).  He explains that in order to maximize the benefits of open source production, a leader must convince others to contribute to his project.  This, in turn, requires “good people and communications skills” (Cathedral and Bazaar 48).  Without such skills, a project faces abandonment by the development community in general.

From each of these lessons we have learned that a successful project requires a leader who will start the code for the project and quickly incorporate the good work of others when possible.  This leader does not need to make his code creative, but the leader does need to creatively draw work out of others.  If these criteria are not met, is there a solution?  How does one work around a leader who fails in any or all of these areas?  Before we search for the answers, we need to understand the rest of the OSS dilemma.

Poor leadership is not the only reason that OSS is abandoned.  While working with Drupal, I learned that the Drupal developers actually planned to abandon Drupal every few years.  In fact, while working this summer on my company’s website I wrote up a document detailing how our company should respond to the Drupal developers’ plans.  Our issue was this: although the Drupal community does not entirely abandon Drupal, every few years they release a new major version of their software and abandon the old version.  Although some aspects of Drupal-built sites upgrade smoothly, others do not.  Thus, if a website is complex, large portions may have to be reconstructed during an upgrade.

I will explore four solutions for this challenge and the other challenges that the users of abandoned OSS face.  While the first solution, “forking,” directly addresses the issue of poor leadership, the other three solutions do not correlate with specific issues.  Consider the second and simplest solution: avoid OSS.  This option could be a solution to poor leadership, but it could also be a solution to other challenges arising from abandoned OSS.   The third solution is to hire a private developer.  If a particular OSS almost works for a user, a privately paid developer can adapt the software so that it suits the user’s particular needs.  The fourth solution is SaaS (Software as a Service).  I believe that SaaS is both the best solution and will soon be the most widely used solution for problematic OSS.  Paying for open-source SaaS usually involves downloading a free copy of the OSS and subsequently paying a company for tech support and upgrades.  I will now examine each of these solutions from the perspective of users and academics in the field.

The first solution for abandoned OSS is “forking” (Cathedral and Bazaar 72).  Raymond notes that if absolutely necessary, a new leader can “fork” a project (take the source code from a project and start another similar and possibly competing project.)  One of the benefits of most open source licenses is that they allow anyone to do anything with a project’s source code, even start a new project (Cathedral and Bazaar 72).  In light of this benefit, one solution for abandoned open source software users is that, if a leader does a poor enough job, users and developers can find or hire a new leader.

Practically speaking, this solution is a last resort.  One of the major strengths of OSS is the volunteer developer community.  Not only does forking projects split developers into smaller independent groups, but it is also taboo in most OSS communities because of the nature of developer culture (Cathedral and Bazaar 72-73).  In this culture, developers value the recognition they receive for contributing work to the public and forking tends to diminish that recognition (Cathedral and Bazaar 86).   Thus, in most cases, forking a project discourages developer involvement, thereby leaving a project in a worse state than it began.

An alternative solution for users proposed by University of California Berkeley professor David Messerschmitt is avoidance of certain open-source software and investment in proprietary software.  He bases this suggestion on his claim that “[s]oftware offers greater value when it’s a single unfragmented solution, it’s widely used and technically sophisticated, and a great many programmers depend on it” (89).  Substituting proprietary for open-source software has its advantages and disadvantages.  On the one hand, purchasing proprietary software gives the user a company to sue if anything goes wrong.  On the other hand, some users may not have the resources or desire to sue companies in order to guarantee quality.  CEO Bernard Golden notes in his book Succeeding with Open Source that “having a commercial provider standing behind a product is no guarantee of responsible behavior.  The software industry has witnessed many instances of companies abruptly declaring products ‘no longer supported’ or defining them as having reached their ‘end of life plan’” (23).  While some users may be satisfied with a company’s guarantee, other users may require a different solution for their abandoned OSS.

Perhaps the solution for these users is to hire software developers.  Countering Professor Messerschmitt’s argument for using proprietary rather than open source software, OSS activist Eric Raymond explains that “[m]ost of the objections in [David Messerschmitt’s] essay can be met with the simple observation that nothing in open source development stops users from paying programmers to get slick user interfaces or anything else they want” (“Eric responds” 91).  Raymond builds on the fact that unlike proprietary software, open-source software can be modified by anyone who can program.  This summer I watched this solution (modifying OSS with hired developers) in action while working for a company that used an open-source program to build their website.  While the open-source program was useful for the basic architecture of my employer’s site, he still hired developers to personalize his site.  Like the first solution to abandoned OSS, hiring developers has its pros and cons.  Some users require products tailored to their personal or corporate situations.  For these users, hiring a developer might make perfect sense.  For other users who do not want to work with a developer, proprietary software may be a better option.  Proprietary software is particularly more effective if the user has reasonable faith in the proprietary provider.

Perhaps the best solution for the users of abandoned open source software is SaaS (software as a service).  SaaS companies sell support for major OSS projects.  For instance, Dries Buytaert has started a SaaS company called Acquia that sells support for Drupal (Acquia, “Dries Buytaert”).  Regardless of the state of the community, SaaS companies can provide support whenever volunteers are lacking.  While I watched the Drupal community work nicely together, their support system was far from perfect.  Volunteers answered questions when they were interested.  Some questions would be answered brilliantly and quickly, while others would fade into obscurity untouched.  On the other hand, Acquia offers support around the clock for Drupal users (“Drupal support and cloud services”).  Acquia can serve the “abandoned” users of Drupal.  Given their potential, SaaS companies seem to be the up and coming solution for abandoned open source software.

Nevertheless, the prospect of open-source software as a service raises a question, why pay for SaaS if the goal of OSS is to cut costs?  The answer depends on the user.  If I were to create a personal website using Drupal, I would not invest in Acquia because a personal website does not merit that expense.  On the other hand, when the federal government designed the White House website using Drupal, investing in Acquia’s services was an appropriate choice (Winikates; Buytaert).  The government needs the White House website to be reliable, and has the funds to make it that way.  All the same, why stick with open-source?  Even with increased support costs, CEO Bernard Golden affirms that “Open source support costs are typically much less expensive than their commercial counterpart” (136).  Golden explains that buying proprietary software support is usually more expensive than OSS support because proprietary support is bundled with the cost of the product.

A second hurdle for SaaS as a solution for abandoned OSS is explained by SaaS guru Joel York.  Joel York devotes much time and energy to explaining why many SaaS companies fail due to poor business models (York).  A high rate of SaaS company failure might make SaaS seem like a poor solution for OSS failure.  This issue (abandoned SaaS) is perhaps the most difficult to resolve.  One way to resolve the issue is to revert to the other solutions for abandoned OSS if the SaaS company fails.  Another way to fix the SaaS company problem is to treat it like any other long-term purchase.  Think of purchasing SaaS like purchasing a car.  If we are worried that an auto dealer will go bankrupt before our warranty expires, we can look at the company’s history and estimate the risk.  In the same way, because SaaS inherently involves a business, users can examine the SaaS company’s history and estimate its risk.  Although such a risk is not ideal, it is an inherent aspect of purchasing any item that is required to last.  Thus we see that SaaS is still a worthy solution for the users of abandoned OSS.

While some may champion the overall effectiveness of one solution over another, Bernard Golden aptly notes that of the multiple tech support solutions available for open-source software, no one solution is inherently greater than the others (126).  He explains that different solutions will fit different users.  That said, in many cases SaaS seems to be the most probable fit for their situation.  Thus, while there may be several solutions for the users of abandoned OSS, the most promising solution appears to be SaaS built around OSS.  With SaaS, OSS will no longer be a tree that falls soundlessly in a forest of programs.  SaaS will make OSS heard.  SaaS will bring support for abandoned users.  SaaS will make open source software matter.