An interview with Peter Morris, program manager and Justin Codd, systems architect on open source products used in a solution for the largest British college exam board Assessment and Qualifications Alliance (AQA). The project requirements were a secure extranet capable of delivering materials to 35,000 examiners and moderators at low cost. Also, meet an insanely tight schedule of 6 weeks to deploy, test and get it into production. Optaros consultants were hired to work with existing team members on integrating open source technology with their existing architecture.

Cost savings are believed to be in the range of £100,000, mostly just in printing and shipping costs for the required materials. Lessons learned – could be applied to most any project. Morris and Codd’s Dos and Don’ts for taking the open source path:

Do…

Apply the same levels of due diligence and assessment applied to open-source-based products to any other proprietary solutions that may also be in the running.

Carefully research the reputation and operational models of any organizations whose open-source products and services you are investigating for eventual deployment.

Clearly communicate with management the aims and goals of assessing and implementing open-source products and regularly brief them with progress.

Evaluate and assess any candidate open-source products and services against a common benchmark incorporating any key business specific requirements in the assessment.

Examine subscription (licensing) and support models of open-source solutions, and understand how they contrast with proprietary commercial software vendors models.

Understand how open-source software and services compare and contrast with proprietary commercial products.

Don’t….

Skimp on conducting comparative evaluations and assessments.

Assume that open-source technologies can necessarily be implemented to a quicker timescale or a lower manpower overhead than proprietary ones.

Assume that you will always be able to find a viable open-source product to service your particular set of organizational or technical requirements: so be realistic and pragmatic when presenting the case for open-source to management.

Skimp on support or rely on community support alone for important systems and services.

Make your organization’s first venture to open source higher-risk than it needs to be. Explore running open-source alongside existing proprietary software.

Overlook or ignore the gap that may exist between the current skills of staff and those that may be required to use/operate any new open-source products or services that are introduced into an organization.

This Week’s Episode