Developing with Open Source Software

1. Developing with Open Source Software March 27, 2006 CIS6515 Yuko Yamamoto

2. What does “open source” mean? What is “open source”? Common characteristics • They adhere to the Open Source Definition. • 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.

3. OSD: Three main criteria • Ability to distribute the software freely • Source code’s availability • Right to create derived works through modification

4. 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

5. 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

6. 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

7. 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

8. 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 to power.

9. A classification of open source users and developers

10. Variable characteristics - Software development support Software development support • Modularity • Visibility of software architecture • Documentation and testing • Accepting submissions • Tool and operational support

11. 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.

12. 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 submissions.

13. 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.

14. 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.

15. 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

16. Phase 1: Desktop and desktop-productivity tools Phase 2: Application-support solutions

17. 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

18. 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

19. 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.

20. 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.

21. 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

22. Phase 2 • Phase 1 largely relies on selecting and implementing generic products. • Phase 2 has focused on application-support solutions.

23. 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.

24. 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.

25. 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.

26. 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.

27. Cost comparison Initial saving: €4.7 mil. over 5 yrs: €8.2 mil. Initial saving: €6.5 mil. over 5 yrs: €12 mil.

28. 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.

29. 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.

30. 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 tissue-matching system, and a casualty system) available as OSS.

31. 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

32. 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.

33. 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.

34. 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)

35. 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.

36. 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.

37. 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.

38. 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.

39. 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.

40. 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.)

41. 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.

42. 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.

43. 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.

44. 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.

45. 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.

46. 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

47. Thank you !!