Open Source Slides - Yuko

495 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
495
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Open Source Slides - Yuko

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

×