November 2007

"The primary hurdles to increasing adoption of F/LOSS software in the sector are missing applications, lack of information about support options, lack of training and familiarity of nonprofit staff on F/LOSS applications, and, finally, perception... There is still the perception that F/LOSS is harder to support, or that it's not possible to find support for F/LOSS."

NOSI Primer

In 2004, the Nonprofit Open Source Initiative (NOSI) released Choosing and Using Free and Open Source Software: A Primer for Nonprofits. The primer describes the potential impact that Free/Libre and Open Source Software (F/LOSS) might have on the not-for-profit (NFP) sector. In a recently released update, the primer concludes that, despite many advances in the use of F/LOSS in the sector over the past several years, a real and perceived lack of support remains a significant barrier to the increased adoption of F/LOSS by NFPs.

Support is often the last thing people think of when they think of F/LOSS and NFPs. Instead, people tend to focus on the price, which is of particular importance to cash-strapped NFPs. There is a widely held belief that free software represents a cost savings to NFPs.

Major software vendors such as Microsoft, Adobe, and Symantec have software donation programs to support charitable organizations. Some donation programs are also available to support NFPs, schools, and/or libraries. Initiatives such as TechSoup Stock are often used to facilitate these and other donation programs for a small administrative fee. (Editor's note: reduced/free licenses for institutions to use commercial software typically do not include support for that software).

Whether the application itself is free or not, the cost of the software is often a small percentage of the Total Cost of Ownership (TCO). Even when donated at low or no cost, proprietary, closed-source software often comes with regressive licensing schemes that can seriously limit an organization's ability to deploy the software effectively. Proprietary data structures and file formats can also be very detrimental to NFPs, since continued access to their data may increase costs later when their upgrade path consists solely of expensive proprietary options.

Support factors into the TCO as well. While licensing schemes and file formats are strikes against proprietary, closed-source software, the availability of support from a software vendor can be a big plus. F/LOSS products often have no vendor, so support can be harder to come by. Support to initially install, and then use, the software is often required for both commercial software and F/LOSS.

Lifecycle Support

There is another element of support that is important to consider: the lifecycle of the software itself. With commercial software, there is a reasonable expectation on the part of purchasers that the vendor will continue to develop the software, fix bugs, and release updates. When it comes to lifecycle support, F/LOSS is sometimes said to have an advantage because of the access to the source code that is inherent to the development model, and the often imagined army of developers around the world who contribute freely to the development of the software.

In terms of lifecycle support, the advantage of F/LOSS is significant for large scale development of widely used utility type software.Utility type software includes operating systems, common server applications, and common desktop applications. Some paragon examples are Linux, Apache, Mozilla Firefox, and OpenOffice.org. However, the vast majority of F/LOSS is not that broad in its appeal or utility, and the needs of any particular organization, NFP or otherwise, will necessarily include some niche applications.

In the case of niche applications, F/LOSS alternatives may have only a handful or even a single developer. The pool of users can also be small, negating the F/LOSS truism that "given enough eyeballs, all bugs are shallow". If there aren't enough eyeballs, carrying out lifecycle support on F/LOSS can be exceptionally difficult for the few who persevere to do so. Or worse, the maintainers can give up and abandon the software. In that case, users are left with the source code, so they are not completely lost, but unless they also have access to programming expertise, they might as well be lost. Lifecycle support is a serious issue to consider in the adoption of F/LOSS. The strength of the specific open source community behind the software is at least as important as the strengths of the software itself.

Additional Constraints for NFPs

The issues noted above--cost, licensing, file formats, support, and lifecycle support--should be familiar to users and potential users of F/LOSS. The specific constraints of typical NFP organizations cast these issues in a particular light.

First and foremost, NFPs typically have less money than for-profit organizations with a similar number of staff or similar operational needs. NFPs usually lack a predictable revenue stream. Much of their funding comes in the form of grants, many of which are tied to specific projects. There is tremendous pressure to reduce overhead costs by focusing only on the barest essentials. It is rare for a NFP to have an IT department, or even staff with advanced knowledge of IT. This makes F/LOSS attractive because of the costs, but highlights the support need due to the lack of skilled staff within the organization.

Maintenance of software can be a significant challenge in NFPs, especially the maintenance of niche applications. The challenge is due to the lack of skilled IT staff and/or the focus on project-based funding rather than operational funding. To be successful, software applications deployed in NFPs should be as close to "zero maintenance" as possible. While users may never need to upgrade their copy of OpenOffice.org to remain productive and effective in their jobs, the same cannot be said of niche applications unique to a particular NFP.

NFPs often experience a high turnover in their human resources, especially volunteers. High turnover makes the effective use of software applications extremely challenging as each subsequent round of users only scratches the surface of the system. A particular emphasis on usability and training can alleviate some of these issues. However, due to financial constraints, most NFPs are not interested in spending money on usability. Moreover, training is only feasible if there is an available support organization which can provide it.

Lastly, NFPs almost always lack any sort of Wide Area Networking (WAN) connectivity between their office locations, and/or a Virtual Private Network (VPN) between their staff. In some cases, there is no real office and everyone works from home, or working from home is a large part of the way the NFP gets things done. Often, the network available to people in a NFP organization is the Internet. This means that Internet-based software, and particularly web-based software, is of singular importance to NFPs.

If an Internet-centric approach is to be successful, all potential software applications must be analyzed from the perspective of how Internet-aware they are. For example, a desktop conference registration database is useful, but not nearly as useful as one that allows many staff from their home offices to access a common database through the web.

In light of these unique constraints that are common to many NFPs--scarce revenue, lack of skilled IT staff, high turnover, and no common network--the only traditional benefit of F/LOSS that aligns with the needs of NFPs is the low cost. With regard to a lack of skilled IT staff, for instance, whether an application is F/LOSS or commercial software is completely irrelevant. What is especially relevant in a NFP context is support. The NOSI primer is correct that a real or perceived lack of support is a barrier in the adoption of F/LOSS, but what is equally important to appreciate is that support is a more fundamental issue for NFPs than for other kinds of organizations.

Technology Assistance Providers

Organizations like Freeform Solutions have emerged to provide support and assistance to NFP organizations. Sometimes called Technology Assistance Providers (TAPs), these organizations provide a variety of services to NFPs, often specializing in a certain kind of work. In some cases, TAPs are for-profit organizations, in other cases they are co-ops, collectives, or, as in the case of Freeform Solutions, they are NFPs themselves. The unifying factor is that they all seek to support NFPs in the use of OSS.

TAPs can help with support at all stages of using software. They are focused on understanding the F/LOSS landscape so they are familiar with the available software applications, and have expertise in installing and supporting them. Some TAPs are also capable of building or customizing particular applications, including niche ones.

At Freeform Solutions, a partnership approach has been found to be the most effective way to provide support. Because of the constraints NFPs operate under, they often do not know what they do not know. They are not only unaware of the available software options, but also of the nature of their problems from an IT perspective.

NFPs, within their domain of expertise, understand their problems and their needs. However, they lack the ability to translate those needs into prescribed software and IT solutions. When NFPs have particular software solutions in mind, it is just as often because someone heard something that sounded interesting, or they read a magazine article about a trend or buzzword, as it is because they have considered the problem space and the available solutions.

To address this, a TAP can closely partner with an organization to understand their needs from the inside out. A TAP that already knows the F/LOSS space and which fully understands an organization's needs can bridge the gap of understanding. In terms of addressing lifecycle support, a TAP with development expertise is uniquely positioned to provide the kind of reassurance for a F/LOSS application that a commercial development team can provide for commercial software. Just like Microsoft has its own programmers on staff, and IBM provides developers to support Linux and other F/LOSS projects, TAPs can provide some development resources to F/LOSS projects. This has many beneficial effects, including improving the TAPs' ability to provide lifecycle support for a client, as well as improving the success of the particular F/LOSS project, which in turn should attract more developers to that particular open source community, which in turn improves the lifecycle support generally available for that F/LOSS project.

However, unless a TAP has some independent revenue stream of its own that it chooses to expend on a F/LOSS project, it is not feasible for a TAP to devote a great deal of development effort to a particular F/LOSS project. Development is expensive, and one of the reasons NFPs are interested in F/LOSS in the first place is the low cost. It is unreasonable to expect that the money paid by a NFP to a TAP would be sufficient to fund significant development efforts, unless the TAP has many clients using the same software.

Development Commons

When a TAP supports many users of a given software, that TAP can leverage the small contributions of all clients towards the development of additional software. TAPs that pursue this approach can be especially valuable to NFPs because their development effort translates into significant expertise in the software, expertise now at the disposal of the NFP, without the organization having to fund development.

In essence, a TAP so engaged is an economic manifestation of the open source philosophy of sharing, and the clients are all participants in open source through their relationship with the TAP.

At Freeform Solutions, this approach is dubbed the "development commons". A particular area of our focus is the development of a generalized software toolkit that can be configured to provide a wide range of applications on the same code base. This allows a supplier to meet the needs of many clients, including those with niche requirements.

This approach is also effective at addressing the "zero maintenance" requirements of NFPs. Because the development effort is shared among many clients and the larger community around the F/LOSS project, clients can expect periodic updates even when they are making no direct contributions themselves.

The basis of the generalized toolkit is the abstraction of many applications so they can be described functionally as a series of forms and reports tied to a database. The toolkit allows for the creation of forms and reports without the need to custom program behaviours and logic into the application. When new needs arise for which there is no configuration option, we add that capability to the code base; all other applications based on the same system benefit from the addition after the next upgrade.

For example, imagine a conference registration system that uses one form to be filled out by conference registrants. Several reports may be necessary, such as a list of registrants' names for creating badges, a payment report for accounting purposes, and a summary of food choices for use by meal planners. Each report is simply a different view of data submitted to the same form. The generalized toolkit provides the capability to create the form by specifying the questions required, and what type of form element, such as a textbox or dropdown list, each question uses. The logical and behavioural properties of the form and the questions can be specified, such as "visible only to accounting staff". The toolkit includes the ability to build reports with a graphical user interface which doesn't require knowledge of SQL, and which allows for customizing the appearance of the results. The end product is a series of screens which can be tied into a menu or any other navigation structure that makes sense given the particular workflow of the application.

A key concept of this software is the distillation of niche application requirements into generalized capabilities. So rather than custom coding a part of a form to be visible only to certain people, the capability is added to make any question visible or not visible to a pre-defined group of users.

We have found this approach to be effective at empowering NFPs to use software effectively, and for enabling the rapid deployment of services. This approach is cost effective for deploying and maintaining services to NFPs, since it minimizes the custom work required, and standardizes the deployments on a common code base. The administrative interface for the generalized software toolkit can be used by NFP staff, without the need for them to operate at the API level of many programming abstractions, which would limit their usefulness to programmers only. Since NFP staff have access to the same software tools that Freeform Solutions itself uses, through an interface they can learn and become comfortable with, it enables a different kind of "zero maintenance" for NFPs. Although staff time is not free, it is in some cases a more affordable alternative than paying money to an outside group for maintenance.

Conclusion

Support, encompassing traditional installation, desktop, and software lifecycle support, is a significant issue for NFPs. The emergence of TAPs has helped mitigate the installation and desktop support issues. Certain kinds of TAPs can also provide lifecycle support, which is equally necessary for successful adoption of F/LOSS, especially the more specialized, niche applications. The NOSI primer has correctly identified that support for F/LOSS continues to be a barrier to adoption. However, various ways to overcome that barrier now exist. As TAPs become more experienced in serving the NFP sector, the end result can be a win-win for both NFP users and F/LOSS projects as the user base and NFP contributions to projects increase.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!

Comments

I've made a OSS (open source software) comparison article. I'm comparing WordPress, Joomla and Drupal. The comparison is located here: http://websitesetup.org/cms-comparison-wordpress-vs-joomla-drupal/

Thanks,
Robert