Saturday, December 12, 2009

Considerations before Making a Selection Based on FOSS

As I mentioned previously, the Free Software Foundation (FSF) and Open Source Initiative (OSI) require, in their definitions that the source code to FOSS be available. The way that source code is kept freely available is through a license, the most common of which is the GNU General Public License (GPL) developed by the FSF. These licenses all stipulate different requirements on the treatment of the source code availability, so one cannot make many generalizations on the requirements of FOSS insofar as when or how people can access the source code. One must look at the individual FOSS license a project is using. Some lists of common FOSS licenses (like the GPL, Mozilla Public License, Apple Public Source License, or the BSD license) are available at the FSF license page or the OSI license page.

Offerings

Review the services offered by leading companies in the open source operating system space. Novell (SUSE), Red Hat, and Progeny all emphasize the types of implementation, migration, support, and customization services they offer. Novell points out (at length) processes involved for a successful enterprise Linux migration. Red Hat promotes its support subscription service to keep its customers up-to-date with patches, recent software updates, and expert support facilities. Progeny wants to customize and modify a Linux system specific to its customers needs.

In every case, those companies are capitalizing on, and participating in the FOSS project communities that produce GNU/Linux systems. Some companies argue that FOSS methodologies work fine for commodity systems but will not work for more specialized enterprise solutions. That doesn't seem to be the case though, as recently enterprise applications are beginning to climb out of the woodwork (a few examples include GNU Enterprise, ComPiere, Anteil, Project/Open, SugarCRM, JetBox CMS, MamboCMS, and the Zope application server).

While researching an open source solution or related engagement consider the following items:

What kind of pre-installation and post-installation support does the maintainer or partner offer?

Analysis of current systems and processes (previous to a new implementation or migration), ongoing support, and service level agreements, are all important to successful operations.

Does the open source project maintainer (vendor) work through local implementation partners? Vertical industry specialists?

Some open source projects or else vendors that offer open source, prefer to let their partners focus on consulting, implementation, and integration services. These vendors support their partners but feel the partners are best able to support clients in their own immediate geographic regions. If that is the case, there are some questions to ask about how the partner interacts with the core project.

* How does the partner contribute to the core project?
* Is there a partner certification program?
* Is there a training program?
* What is the partner's expertise with Free and open source software?
* What kind of geographic presence and industry experience is offered?

Is there on-line availability of project tracking?

As a company chooses to use open source, it is important to gauge the open source project's viability. Users of open source applications need to be reassured about a given project's future. Thus visibility into the project roadmap, user issues, bug fixes, and feature requests is necessary for clients to verify that the project maintainers actively coordinate development on the community's goals. Open source projects that run astray of their goals or alienate their developer community are not likely to instil the trust necessary to continue as a successful project.

1 comment:

  1. Thus visibility into the project roadmap, user issues, bug fixes, and feature requests is necessary for clients to verify that the project maintainers actively coordinate development on the community's goals.


    Granular Sewer Line Maintainer

    ReplyDelete