Open Source Software enegineering


Published on

1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Open Source Software enegineering

  1. 1. Open Source Software Engineering Luca Pastorino
  2. 2. Summary <ul><li>Open Source and Free Software </li></ul><ul><li>Development Process in Open Source </li></ul><ul><li>Reasons of Open Source Success </li></ul><ul><li>Corporate Source </li></ul>
  3. 3. Summary <ul><li>Open Source and Free Software </li></ul><ul><li>Development Process in Open Source </li></ul><ul><li>Reasons of Open Source Success </li></ul><ul><li>Corporate Source </li></ul>
  4. 4. Free Software / Open Source <ul><li>Same “enemy” (proprietary software) </li></ul><ul><li>Are distinct and have different targets </li></ul><ul><li>Free Software </li></ul><ul><ul><li>software must be “free” for social end ethic reasons (not gratis) </li></ul></ul><ul><ul><li>users must have freedom </li></ul></ul><ul><ul><ul><li>to run the program </li></ul></ul></ul><ul><ul><ul><li>to study how the program works </li></ul></ul></ul><ul><ul><ul><li>to r edistribute copies </li></ul></ul></ul><ul><ul><ul><li>to modify and improve the program </li></ul></ul></ul><ul><li>Open Source </li></ul><ul><ul><li>source code must be open and readable for practical reasons: it is a development method </li></ul></ul>
  5. 5. The GNU Project and the Free Software Foundation <ul><li>1984: initial announcement of the GNU Project by Richard Stallman </li></ul><ul><ul><li>Developing a complete UNIX style Operating System as free software : the GNU (GNU's Not Unix) </li></ul></ul><ul><li>1985: Free Software Foundation </li></ul><ul><ul><li>Promoting the development and use of free software, particularly the GNU Operating System </li></ul></ul>
  6. 6. Open Source <ul><li>1998: Bruce Perens, Eric Raymond and others in the Free software sector, realised that the business world didn’t like the freedom principle associated with it </li></ul><ul><ul><li>Promote Free software to highlight the many advantages such as adaptability, reliability, security, standard conformity and indipendence from single companies </li></ul></ul><ul><ul><li>Open Source Definition : the fundamental document of the O pen Source community </li></ul></ul>
  7. 7. The Open Source Definition <ul><li>Free Redistribution </li></ul><ul><li>Source Code Distribution </li></ul><ul><li>Derived Works Allowed </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>License Must Not Restrict Other Software </li></ul><ul><li>License Must Be Technology-Neutral </li></ul>
  8. 8. Open Source Products <ul><li>Operating System </li></ul><ul><ul><li>Linux </li></ul></ul><ul><ul><li>BSDs (Berkeley Systems Distribution of Unix) </li></ul></ul><ul><li>Internet </li></ul><ul><ul><li>Apache </li></ul></ul><ul><ul><li>BIND </li></ul></ul><ul><ul><li>Mozilla </li></ul></ul><ul><li>Programming Tools </li></ul><ul><ul><li>Perl , Zope and PHP: popular engines behind the &quot;live content&quot; on the World Wide Web </li></ul></ul><ul><ul><li>The GNU compilers and tools (GCC, Make and others): the most powerful, flexible and extensible set of compilers in the world </li></ul></ul>
  9. 9. Open Source Companies <ul><li>IBM : Use of Apache to support WebSphere, Eclipse </li></ul><ul><li>APPLE : Darwin, Quick Time Streaming server </li></ul><ul><li>HP : Linux on its servers and handhelds </li></ul><ul><li>SUN : Support Java and Mozilla projects </li></ul><ul><li>Sharp : Linux on Zaurus handhelds </li></ul><ul><li>Red Hat Software : Linux distribution </li></ul><ul><li>Open Source in Government and Non-Profit </li></ul>
  10. 10. Summary <ul><li>Open Source and Free Software </li></ul><ul><li>Development Process in Open Source </li></ul><ul><li>Reasons of Open Source Success </li></ul><ul><li>Corporate Source </li></ul>
  11. 11. A new SE paradigm <ul><li>Technically, OOS (Open Source Software) is defined in terms of distribution licenses, not developmental methods </li></ul><ul><li>Intuitively, the development process supported by OSS promises something new to Software Engineering </li></ul><ul><li>The principles of OSS development are showing, in a new way, how complex software systems can be constructed, deployed and evolved </li></ul>
  12. 12. Taxonomy of Open Source Development <ul><li>The term “Open Source Software development” is over-loaded </li></ul><ul><li>There are three major focuses: </li></ul><ul><ul><li>Archetype: a high quality program as a reference model (GNU software) </li></ul></ul><ul><ul><li>Security: software fault-tolerance (PostgreSQL) </li></ul></ul><ul><ul><li>Rapidness: rapid adaptation and modification (Linux, excl. kernel) </li></ul></ul>
  13. 13. Open Source Communities Core team Co-developers Active User Passive User Initiator Release coordinator .
  14. 14. Software Engineering Process <ul><li>The elements of a typical software engineering process are generally enumerated as: </li></ul><ul><li>Requirements Analysis </li></ul><ul><li>System-Level Design </li></ul><ul><li>Detailed Design </li></ul><ul><li>Implementation </li></ul><ul><li>Integration </li></ul><ul><li>Field Testing </li></ul><ul><li>Support/Maintenance </li></ul>
  15. 15. Requirements Analysis <ul><li>Conventional Software: </li></ul><ul><li>Create a document which describes the target customers, their reason for needing this product and the list of features of the product </li></ul><ul><li>Open Source Software: </li></ul><ul><li>Usually Open Source folks tend to build the tools they need </li></ul><ul><li>Use of mailing lists or newsgroups </li></ul>
  16. 16. System-level Design <ul><li>Conventional Software: </li></ul><ul><li>High-level description of the product, in terms of modules and of the interaction between them </li></ul><ul><li>Open Source Software: </li></ul><ul><li>There usually is no system-level design </li></ul><ul><li>The system design is implicit or it evolves over time </li></ul><ul><li>Usually by version 2 or 3 of an open source system, there actually is a system design </li></ul>
  17. 17. Detailed Design <ul><li>Conventional Software: </li></ul><ul><li>Every module defined in the system-level design is described in detail </li></ul><ul><li>The interfaces of each module has to be determined as well as dependencies between modules </li></ul><ul><li>Open Source Software: </li></ul><ul><li>Detailed design ends up being a side effect of the implementation </li></ul><ul><li>Documenting the API is optional and may not occur if the API isn’t intended to be used outside the project </li></ul>
  18. 18. Implementation <ul><li>Conventional Software: </li></ul><ul><li>Every module described in the detailed design has to be implemented </li></ul><ul><li>A module can be considered implemented when it has been created and tested </li></ul><ul><li>Open Source Software: </li></ul><ul><li>This is the fun part </li></ul><ul><li>The opportunity to write code is the primary motivation for almost all open source software development efforts </li></ul><ul><li>Review is informal </li></ul><ul><li>No unit test </li></ul>
  19. 19. Integration <ul><li>Conventional Software: </li></ul><ul><li>When all modules are complete, system-level integration can be done </li></ul><ul><li>All modules are compiled, linked and packaged as a system </li></ul><ul><li>It usually includes the development of a system-level test </li></ul><ul><li>Open Source Software: </li></ul><ul><li>It involves writing some man pages, making sure that it builds on every kind of system, writing a Makefile, writing a README, making a tarball, putting it up for anonymous FTP somewhere, and posting a note to a mailing list or newsgroup </li></ul>
  20. 20. Field Testing <ul><li>Conventional Software: </li></ul><ul><li>Field testing usually begins internally (from employees of the organization) </li></ul><ul><li>Then, it will be necessary to run the software esternally (on customers’ computer) </li></ul><ul><li>Open Source Software: </li></ul><ul><li>The best system-level testing in the industry: users are friendlier when they aren’t charged any money, and power users are more helpful when they can read and fix the source code </li></ul><ul><li>Real world experience of real users </li></ul><ul><li>“ peer review” of hundreds of other programmers </li></ul>
  21. 21. Support and Maintenance <ul><li>Conventional Software: </li></ul><ul><li>Sofware defects are recorded in a tracking system </li></ul><ul><li>These defects are assigned to a software engineer who will propose a change to either the documentation or the implementation </li></ul><ul><li>Open Source Software: </li></ul><ul><li>When a user finds a bug he can report it an a mailing list, or also send a patch </li></ul><ul><li>Sometimes this phase is provided under some payment </li></ul>
  22. 22. Configuration Management Conventional change process Change process for OSS
  23. 23. Summary <ul><li>Open Source and Free Software </li></ul><ul><li>Development Process in Open Source </li></ul><ul><li>Reasons of Open Source Success </li></ul><ul><li>Corporate Source </li></ul>
  24. 24. Reasons of Open Source Success <ul><li>From an end-user perspective: </li></ul><ul><li>reduces the cost of software acquisition </li></ul><ul><li>enables diversity </li></ul><ul><li>simplify collaboration </li></ul><ul><li>From a software process and productivity perspective: </li></ul><ul><li>Enlarging the user community </li></ul><ul><li>Scalable division of labor </li></ul><ul><li>Short feedback loops </li></ul><ul><li>Greater oppotunity for analysis </li></ul>
  25. 25. Why do developers contribute to Open Source Projects? <ul><li>Personal needs </li></ul><ul><li>Enjoyment </li></ul><ul><li>Desire to be part of a team </li></ul><ul><li>Reputation </li></ul><ul><li>Money </li></ul>
  26. 26. Where OS Succeeds and Fails <ul><li>Successful domains </li></ul><ul><li>Communities with unmet software needs </li></ul><ul><li>Technically sophisticated user community </li></ul><ul><li>General-purpose, commoditized, infrastructure software </li></ul><ul><li>Unsuccessful domains </li></ul><ul><li>Highly vertical domains </li></ul><ul><li>Highly competitive domains </li></ul><ul><li>Highly secure domains </li></ul><ul><li>High-confidence domains </li></ul>
  27. 27. Summary <ul><li>Open Source and Free Software </li></ul><ul><li>Development Process in Open Source </li></ul><ul><li>Reasons of Open Source Success </li></ul><ul><li>Successful and Unsuccessful Domains </li></ul><ul><li>Corporate Source </li></ul>
  28. 28. Corporate Source: OS Concepts to a Corporate Environment <ul><li>Corporate Source is the application of OS concepts and methodologies within the corporate envirorment </li></ul><ul><li>“ Open” to all developers behind the firewall </li></ul><ul><li>Community size is smaller than the Internet </li></ul>
  29. 29. Why is Corporate Source good? <ul><li>Quality </li></ul><ul><ul><li>Programmers write better code for sharing vs. just execution </li></ul></ul><ul><li>Code Sharing </li></ul><ul><ul><li>Corporate Source will promote greater sharing of code among different projects </li></ul></ul><ul><li>Maintenance </li></ul><ul><ul><li>Bugs get fixed faster, and features added faster, if more people understand and can modify code </li></ul></ul><ul><li>‘ Bit Rot’ Protection </li></ul><ul><ul><li>Prevent code from ‘bit rot’ </li></ul></ul><ul><li>Intellectual Property </li></ul><ul><ul><li>Code is IP that must be protected and widely utilized </li></ul></ul>
  30. 30. References <ul><li>Open Source Initiative - </li></ul><ul><li>GNU project and FSF - </li></ul><ul><li>Institute for Software Research - </li></ul><ul><li>AICA group - http:// / </li></ul><ul><li>“ Open Sources: Voices from the Open Source Revolution”, e dited by DiBona, Ockman, Stone, 1st Edition January 1999 </li></ul><ul><li>“ Understanding the Requirements for Developing Open Source Software Systems”, Walt Scacchi - Institute for Software Research, University of California, Irvine </li></ul><ul><li>“ Making Sense of the Bazaar”: 1st Workshop on Open Source Software Engineering” - http:// /icse2001/ </li></ul><ul><li>“ Meeting Challenges and Surviving Success”: 2nd Workshop on Open Source Software Engineering - http:// /icse2002/ </li></ul>
  31. 31. References <ul><li>“ Taking Stock of the Bazaar”: 3rd Workshop on Open Source Software Engineering </li></ul><ul><li>“ Leveraging Open-Source Communities To Improve the Quality & Performance of Open-Source Software” – Schmidt, Porter (2001) </li></ul><ul><li>“ Taxonomy of Open Source Software Development” – Nakakoji, Yamamoto (2001) </li></ul><ul><li>“ Configuration Management for Open Source Software” – Asklund, Bendix (2001) </li></ul><ul><li>“ Corporate Source: Applaying Open Source Concepts to a Corporate Environment”- Dinkelacker, Garg (2001) </li></ul><ul><li>“ Why Do Developers Contribute to Open Source Projects? First Evidence of Economic Incentives – Hann, Roberts, Slaughter (2001) </li></ul>