Your SlideShare is downloading. ×
0
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Open Source Software enegineering
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Open Source Software enegineering

702

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
702
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Open Source Software Engineering Luca Pastorino
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Open Source Communities Core team Co-developers Active User Passive User Initiator Release coordinator .
  • 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. 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. 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. 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. 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. 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. 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. 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. Configuration Management Conventional change process Change process for OSS
  • 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. 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. 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. 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. 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. 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. 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. References <ul><li>Open Source Initiative - www.opensource.org </li></ul><ul><li>GNU project and FSF - www.gnu.org </li></ul><ul><li>Institute for Software Research - www.isr.uci.edu/research-open-source.html </li></ul><ul><li>AICA group - http:// linfe.it / </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:// opensource.ucc.ie /icse2001/ </li></ul><ul><li>“ Meeting Challenges and Surviving Success”: 2nd Workshop on Open Source Software Engineering - http:// opensource.ucc.ie /icse2002/ </li></ul>
  • 31. References <ul><li>“ Taking Stock of the Bazaar”: 3rd Workshop on Open Source Software Engineering http://opensource.ucc.ie/icse2003/ </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>

×