open source software: a case study

Open Source Software: A Case Study

Scott A. James,President

Computer Consulting Specialists, Inc.Sarasota, Florida

Scott James Computer Consulting Specialists, Inc. SuncoastLinux.com

What is Open Source Software

• www.opensource.org says 10 things, but we summarize as:• Software in a community that is:

• Freely Used (no warranty, no limits on usage)• Freely Extended (must share source, represent original works and

owners)• Many varieties of licenses, they ARE different.

Know what they mean.

• Check out www.opensource.org for large list and details of each.

http://www.opensource.org/



Summary

A case study of a project created with open source technology.

• Project analysis: Goals & Resources• Technology: TCO, Evaluation & Decision• Implementation: Building the project• Lessons: What was learned• Resources

Project Analysis

What are we doing? What do we have?


Project Analysis: Goals

• Project – functional, scalable, simple.• Timeline – when will each phase roll out?• Budget – how much money do we have?• Longevity – short term utility or long term application?• Equity – invest time in ourselves, or dollars in outside vendors?

Inexpensive, Build Fast, Quality: pick any two.


Project Analysis: Resources

• Staff Knowledge – what is current ability of staff?• Time – how long do we have?• Money – how much do we have?• Technology – what is already in use?

Technology

An Evaluation of Open Source Software


Technology: Total Cost of Ownership (TCO)

• Startup Time: days or weeks?• Development Time: weeks, months, years?• Startup Money: cost of acquisition• Development Money: recurring costs and time.• Equity: $ pay to outside, vs. pay to ourselves• Risk: Dependency on outside trends?• Support: availability? Cost?


Technology: Investigation

• LAMP: Linux, Apache, MySQL, PHP• Windows: ASP/ActiveX, .NET, SQL Server• IBM WebSphere, Sun ONE, HP


Technology: Evaluation for TCO

• Tech staff has both Windows and UNIX background• We have time (several months ok)• Low budget, little money to spend.• Prefer to invest equity in ourselves.• Would like to reduce risk from outside tech trends.• Need solid, reliable server that requires little maintenance.• Need development questions/problems solved, but not real time.


Technology: Decision to use LAMP

• This is a new project (no migration necessary)• Our staff has UNIX (Linux) experience• Large user support community for core technology• Invest into own technology equity• Reduce risk of reliance on technology trends• Low cost to entry (no license or hardware fees)

Implementation

Putting Open Source Software to Work


Implementation: Development Environment

• Linux server, Windows 2000 & XP workstations.• Apache, MySQL and PHP.• CVS & e-mail/IM for configuration management.• Smarty template engine (smarty.php.net)• PEAR application framework (pear.php.net)• SafeSQL - PHP Class to prepare SQL statements

Google to find. Written by author of Smarty.

http://www.smarty.php.net/

http://www.pear.php.net/


Implementation: Linux Server Preperation

• Linux Mandrake (www.mandrakesoft.com)• Apache 2.0 (www.apache.org)• MySQL 3.23 (www.mysql.com)• PHP 4.2 (www.php.net)

http://www.mandrakesoft.com/

http://www.apache.org/

http://www.mysql.com/

http://www.php.net/


Implementation: Development Preparation

• CVS for version control on Linux server• SAMBA for windows networking.• TortoiseCVS on Windows (www.tortoisecvs.org)

Better than WinCVS (it’s a powerful shell extension)• Language syntax sensitive editor (Ultra Edit, Multi-Edit, vim, etc.)• Apache and PHP on local workstations for unit testing (Linux

version on server, Win32 versions on workstations).

http://www.tortoisecvs.org/


Implementation: Development

• Data model with subject matter experts, talk through 1-to-Many relationships, sanity check.

• Design PHP class hierarchy for business N-tier layer.• Create shim PHP classes for web designers to use while building

and testing HTML templates. This provides ability to develop GUI in parallel.

• Smarty template syntax can be HTML syntax compliant for use with Dreamweaver.


Implementation: Open Source value, case in point

• We found a useful PHP class for preparing SQL statements called SafeSQL.

• However, it did not provide all the functionality we wanted.• In about 2 hours we modified the source to add our features.• We then e-mailed a copy back to the author; that these features

may be included in future versions (as he my decide).• We enjoy similar features added by other developers.


Implementation: Use the Support Channels

• Docs (www.apache.org, www.php.net)Save time with on-line look-up (MySQL, PHP)RTFM (Read The Fine Manual)

• www.google.com - Best way to search the Internet.Search for specifics like: functions, methods and error numbers

• Forums (www.phpinsider.com, www.devshed.com)Register early, try to skim articles regularly.

• Wiki – web page self regulated by community, very useful.The Smarty template engine has a great Wiki.

• Plan for time to interact with open source community-- support is usually not real time.

http://www.apache.org/

http://www.php.net/

http://www.google.com/

http://www.phpinsider.com/

http://www.devshed.com/


Implementation: Flexible environment for unit testing

• Perform unit testing on local Windows workstations using Windows versions of Apache, PHP and MySQL.

• Regression testing is desirable, use automated methods as much as possible.

• CVS provides “hooks” to execute scripts on files as they are committed to repository.


Implementation: Deployment on servers

• Deploy using automated script – fewer human actions means fewer mistakes.

• Look at using SSH, TAR, RSYNC for ways to move software between hosts.

• Use CVS to ‘tag’ releases for consistent software bundling. Avoid temptation to copy individual files.

• Adopt versioning nomenclature like: 1.2.4.0-beta1(major.minor.fix.build)

• Batch bugs/features into small groups of changes for frequent (sometimes weekly) updates.

Lessons Learned

What have we learned from our experience?


Lessons Learned: Support

• Subscribe to on-line newsletters early on. Look for digest versions and skim for understanding of product and current support.

• Plan time for support from open source community. Response time may be days.

• Don’t be afraid to ask for help. Be courteous to the open source community.


Lessons Learned: Development

• Do a small project (a prototype) to test development staff and environment. Set goals, and track progress.

• Schedule tasks in parallel to allow for workflow snags and interacting with open source community.

• Use in-source documentation tools (www.doxygen.org, www.phpdoc.de) to aid staff and to monitor progress.

• Tap into local support network early in the project:user groups, business associates, consultants.

http://www.doxygen.org/

http://www.phpdoc.de/


Lessons Learned: Configuration Management

• Frequently commit (check-in) files to CVS and tag frequently (release).

• Goal: Only commit working code, and never tag broken code.• Use CVS for all files, including docs, libraries, binaries. Makes for

easy reproduction of whole environment for reliable testing.• Do unit testing on local workstations with Apache & PHP running

locally. Build this into the design.• Have fun, and learn a lot!


Resources

• Philosophy & Legal:www.opensource.org

• Fun:www.slashdot.org

For these slides and more visit:Computer Consulting Specialists, Inc.

[email protected]


http://www.slashdot.org/

http://www.computercsi.com/

mailto:[email protected]

open source software: a case study

Documents