Developing with Open Source
Software
March 27, 2006
CIS6515 Yuko Yamamoto
1
What does “open source” mean?
What is “open source”?
Common characteristics
1. They adhere to the Open Source Definition.
2. Developers are always users.
•
Open Source Definition (OSD) was composed by
Open Source Initiative (OSI), a non-profit
corporation dedicated to managing and promoting
the OSD for the good of the community.
2
OSD: Three main criteria
1. Ability to distribute the software freely
2. Source code’s availability
3. Right to create derived works through
modification
3
OSD: criteria
•
Six more criteria deal with licensing issues and
spell out the requisite “no discrimination” stance,
that is, anyone can use this software.
4.
5.
6.
7.
8.
9.
Integrity of The Author's Source Code
No Discrimination Against Persons or Groups
No Discrimination Against Fields of Endeavor
Distribution of License
License Must Not Be Specific to a Product
License Must Not Restrict Other Software
4
Variable characteristics

•
•
•
•
•
Project starting points
Motivation
Community
Software development support
Licensing
Size
Project starting points
• Start from scratch
• Convert closed-source software to open source
software
5
Variable characteristics Motivation
Individuals / Corporations
• To satisfy a perceived need
Individuals
• For personal satisfaction
• Strong philosophical beliefs about the resulting software’s
openness
• Peer recognition
Corporations
• To gain market share
• To undermine their competitors
• No need to build an equivalent product from scratch
6
Variable characteristics Community
Community
• Active open source projects have a well-defined
community with common interests, evolving related
products or using results.
• Many open source projects have no clear community
structure or involve just one person.
This characteristic involves two issues:
• Balance of centralization and decentralization
• Meritocratic culture
7
Variable characteristics –
Community (2)
Balance of centralization and decentralization
• Some communities have a strict hierarchy
differentiating various levels of developers
Centralization
• Others have a much looser structure
Decentralization
Meritocratic culture
• Knowledge shown through contributions increases
the contributor’s perceived merit, which in turn leads
8
to power.
A classification of open source users and developers
9
Variable characteristics Software development support
Software development support
• Modularity
• Visibility of software architecture
• Documentation and testing
• Accepting submissions
• Tool and operational support
10
Variable characteristics Software development support(2)
Modularity
• In most cases, well-defined interfaces and
modularized source code are prerequisites because
open source development is usually distributed.
Visibility of software architecture
• An open source software system’s architecture might
be available or not.
11
Variable characteristics Software development support(3)
Documentation and testing
• These two areas are often overlooked or vary widely
during open source development.
• Open source tends to replace the formal testing
process with the “many eyeballs” approach to
eliminating bugs.
Accepting submissions
• Open source projects often have processes for
accepting various types of submissions, while clearly
specifying how to handle multiple concurrent
12
submissions.
Variable characteristics (2)
Tool and operational support
• To facilitate concurrent software development, most
open source projects implement some form of
configuration management.
e.g.) CVS (Concurrent Versions System)
• Communities communicate almost exclusively by
electronic means.
e.g.) mailing lists, newsgroups, web sites
Size
• Size varies widely from project to project.
13
Variable characteristics (3)
Licensing
• Some ensure that if any of the software code is used in other
software development, all the software will come under the
terms of that original license.
• Another aspect of these licenses concerns whether they restrict
distribution of any of the original source code to binary form in
future derived software products.
14
Case study 1
• Beaumont Hospital, Ireland
Reason for moving to Open Source Software (OSS)
Cost

Beaumont’s IT budget has significantly decreased
since 2000 in the wake of Y2K preparation costs. (In
2003 alone, €17 million)
Initial cost saving
Cost savings over years
To get the best possible return for the taxpayers’
money



15
Phase 1: Desktop and desktop-productivity tools
Phase 2: Application-support solutions
16
Desktop applications



Star Office 5.2 desktop suite
Product of Sun Microsystems
Runs on multiple operating systems including
Windows, Solaris, and Linux
Thin-client strategy whereby applications are
downloaded from the network where practical
Users unpredictably lost network connections
17
Desktop applications (2)




Star Office 6
Installed on the desktop instead
Problem of network connections solved
Star Office’s ability to exploit its built-in XML
capabilities
let users’ structured documents incorporate
processing logic
e.g.) After creating an online human resources form, that is then
automatically routed to the HR department for processing
18
Content Management System (CMS)
Digital Creation’s Zope
• Downloadable for free
• Implementation in Beaumont cost €20,000 in terms
of support from a small local software company
• Zope application server lets the IT department
automatically manage documents by using the
metatags associated with each document type
implement rules about how to display information, who is
authorized to see it, who can change it etc.
19
X-ray imaging





Until relatively recently, most hospitals had printed x-ray images.
Now they use digital images.
Beaumont will need to spend an estimated €250,000 to upgrade
its network’s quality to sustain rapid data retrieval.
It will also need to spend approximately €400,000 on additional
high-resolution workstations to ensure that the radiologists can
make safe and consistent clinical diagnosis.
Beaumont have spent approximately €480,000 for x-ray film
annually.
20
E-mail
Before
Lotus Domino
800 user license
Demand to expand email coverage to all 3,000 staff
arose


After
Open source Skyrix e-mail package
all the basic email functions + administrative
functions
E-mail access to all 3,000 staff



21
Phase 2
• Phase 1 largely relies on selecting and
implementing generic products.
• Phase 2 has focused on applicationsupport solutions.
22
Vista hospital system
• Open source VISTA (Veterans Health Information
Systems and Technology Architecture)
• An overall hospital information system
• Developed by the Veterans Administration of the US
Department of Defense
• It has been thoroughly field-tested over 25 years in
the U.S.
23
Compiere financial system
• A fully functional open source financial management
system
• The developers made it available as open source
because they recognized that the marketing
investment necessary to go head-to-head against
the more established financial solutions was so
significant.
24
Payroll system
• Beaumont developed a staff rostering system.
• This area is characterized by a great variation in rules
and work practices.
• In addition, it is necessary to ensure that the requisite
skills, from a medical nursing point of view, are
available on each shift.
25
Payroll system (2)
• The system incorporates rules-based logic – using
the Extensible Business Rules Language (XBRL) to
express it as a set of business rules.
• Beaumont intends to incorporate a payroll capability
in the rostering system and to develop a full payroll
system in XBRL, thus saving the €95,000 annual fee
being paid to a vendor for this service.
26
Cost comparison
Initial saving: €4.7 mil. over 5 yrs: €8.2 mil.
Initial saving: €6.5 mil. over 5 yrs: €12 mil.
27
Lessons learned
• Beaumont perceived a risk in deploying OSS-based
solutions:
Reliance on a standard maintenance contract is
not an option, and bulletin boards might be the
main source of support.


Beaumont’s users have become involved in
identifying and acquiring OSS solutions.
The traditional line between internal IT staff and users
became blurred.
28
Lessons learned (2)
• Because OSS is more or less free, there is often the
misperception that service and support should
also be correspondingly priced.
• Beaumont spent €20,000 for support of Content
Management System.
29
Lessons learned (3)
“Free rider” issue
• Whereby Individuals or organizations merely receive
all the benefits of the OSS development work of
others and never contribute anything themselves
• Beaumont has made several applications they
developed (a staff rostering system, a tissuematching system, and a casualty system) available
as OSS.
30
Lessons learned (4)
• There was a resistance from staff who feared being
deskilled by losing experience with popular
commercial software packages.
• Some users – who either already had current
alternative products or the money to purchase them –
opted not to install Star Office
• Approximately 8% of users
31
Case study 2
• Macadamian Technologies, a software
development firm
• A development team at Macadamian Technologies
was asked to become a major contributor to the Wine
project.
• Wine is an open source implementation of the
Windows API, a compatibility layer that lets native
Windows programs run on X-Windows and Unix.
32
What the Macadamian
Technologies team expected

Chaos in the organization,
development, and code!
The anticipated chaos just did not exist.
• There was a team organization.

33
Team organization
• Developers
• Reviewers
• The committer
Developers
• Unlike commercial software teams, Wine developers
choose their own assignments.
• Most often, they implement features from the Wine To
Do list (http://wiki.winehq.org/TodoList)
34
Team organization (2)
Reviewers
Any developer on Wine can be a reviewer.
When a developer submits code to the mailing list,
anyone can critique it, finding errors and making
suggestions.


The committer
• The top of the leaders, a person responsible for
committing changes to the source tree.
35
Submitting code



A developer submits code to the Wine mailing list.
Anyone on the mailing list can review the code and
submit comments through the mailing list.
The committer makes the final decision to accept the
code or request changes.
36
Concurrent Versions System
CVS (Concurrent Versions System)
• CVS implements a version control system: it keeps
track of all work and all changes in a set of files.
• CVS utilizes a client-server architecture: a server
stores the current version(s) of the project and its
history, and clients connect to the server in order to
check-out a complete copy of the project, work on
this copy and then later check-in their changes.
37
What happened when the Macadamian
team submitted their code?
• When the Macadamian Technologies team submitted
their first patches, they were sent back.
• It was not just the committer who had things to say
about their code.
• For Wine developers, code review happens
automatically.
• No one wants to see bugs into the source tree.
38
Lessons learned
• Bugs were caught earlier in the cycle, before they
were introduced into the source tree.
• Through the mailing list, developers quickly learned
what their common errors were and how to avoid
them.
• When developers took pride in creating patches that
were committed on first pass, they challenged
themselves to produce their best work.
39
Lessons learned (2)
• Junior developers trained quickly, having access to their more
experienced peers.
• The training effort was divided, so one person did not lose a
significant portion of development time to train others.
• Despite the team’s worldwide distribution, the project had a high
level of communication through the mailing list.
• Even though the project was not even close to finished, the
code was constantly ready for release.
(The committer adds code only when it is in a working state, not
before.)
40
Application to non-open source
projects
• The Macadamian Technologies team decided to
apply the procedure to one of their non-open source
projects.
Improvements of the procedure
In their adapted method, the submitting developer
assigns responsibility for review to a team member.
When a reviewer reports a bug, he/she indicates the
bug’s exact location and detailed description of the
problem.


41
Results
Benefits the Macadamian Technologies team had
encountered on Wine crossed over to commercial
development
• Time savings
The single-committer method cuts the time spent
reviewing code significantly.
• Consistent review
The single–committer method builds code review into
daily work as a consistent part of the development
process.
42
Results (2)
• Sharpened skills
Reviewing code often, and in small pieces, keeps
reviewing skills sharp.
• Errors kept out of code base
The only thing better than getting errors out of your
source code is not putting them there in the first place.
• Release-ready code
The committer adds code only when it is in a working
state.
43
Results (3)
• Teaching tool
Developers discover common mistakes and stop
making them.
Having senior developers review new developers’
work gets juniors up to speed quickly.
• Iterative nature
With the single-committer model, a developer gets
the comments and makes changes, then resubmits
the code. The reviewer ensures that the developer
has made the changes without adding any errors
during the fixes.
44
Conclusion
• Although thousands of projects are classified as open
source, they all share only two main characteristics:
adherence to the Open Source Definition; developers
are always users.

Some of the good procedures of open source
projects can be applied to commercial projects. We
should try to adopt them without being constrained by
convention.
45
References
[1] C. Gacek and B. Arief, “The Many Meanings of Open Source,” IEEE Software, Vol. 21,
No. 1, Jan./Feb. 2004, pp. 34-40.
[2] B. Fitzgerald and T. Kenny, “Developing an Information Systems Infrastructure with
Open Source Software,” IEEE Software, Vol. 21, No. 1, Jan./Feb. 2004, pp. 50-55.
[3] S. Lussier, “New Tricks: How Open Source Changed the Way My Team Works,” IEEE
Software, Vol. 21, No. 1, Jan./Feb. 2004, pp. 68-72.
[4] Open Source Initiative. The Open Source Definition [Internet]. c2006.
http://www.opensource.org/docs/definition
[5] Open Source Initiative. Open Source Initiative [Internet]. c2006.
http://www.opensource.org/
[6] J. Green, Wine Wiki. Wine TODO List [Internet]. [last modified 2006 Mar 9].
http://wiki.winehq.org/TodoList
[7] Wikipedia. Concurrent Versions System [Internet]. [last modified 2006 Mar 24].
http://en.wikipedia.org/wiki/Concurrent%5FVersions%5FSystem
46
47