This preview shows page 1. Sign up to view the full content.
Unformatted text preview: 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 Source code's availability Right to create derived works through modification
3 1. 1. OSD: criteria Six more criteria deal with licensing issues and spell out the requisite "no discrimination" stance, that is, anyone can use this software. 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 1. 2. 3. 4. 5. 6. 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.
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 singlecommitter 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
 C. Gacek and B. Arief, "The Many Meanings of Open Source," IEEE Software, Vol. 21, No. 1, Jan./Feb. 2004, pp. 34-40.  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.  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.  Open Source Initiative. The Open Source Definition [Internet]. c2006. http://www.opensource.org/docs/definition  Open Source Initiative. Open Source Initiative [Internet]. c2006. http://www.opensource.org/  J. Green, Wine Wiki. Wine TODO List [Internet]. [last modified 2006 Mar 9]. http://wiki.winehq.org/TodoList  Wikipedia. Concurrent Versions System [Internet]. [last modified 2006 Mar 24]. http://en.wikipedia.org/wiki/Concurrent%5FVersions%5FSystem 46 47 ...
View Full Document
This document was uploaded on 07/29/2011.
- Spring '09