1. Open Source Software Engineering
Luca Pastorino
16/04/2017

2. Summary Open Source and Free Software
Development Process in Open Source
Reasons of Open Source Success
Corporate Source
16/04/2017

3. Summary Open Source and Free Software
Development Process in Open Source
Reasons of Open Source Success
Corporate Source
16/04/2017

4. Free Software / Open Source
Same “enemy” (proprietary software)
Are distinct and have different targets
Free Software
software must be “free” for social end ethic reasons (not gratis)
users must have freedom
to run the program
to study how the program works
to redistribute copies
to modify and improve the program
Open Source
source code must be open and readable for practical reasons: it is a development method
16/04/2017

5. The GNU Project and the Free Software Foundation
1984: initial announcement of the GNU Project by Richard Stallman
Developing a complete UNIX style Operating System as free software: the GNU (GNU's Not Unix)
1985: Free Software Foundation
Promoting the development and use of free software, particularly the GNU Operating System
16/04/2017

6. Open Source
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
Promote Free software to highlight the many advantages such as adaptability, reliability, security, standard conformity and indipendence from single companies
Open Source Definition: the fundamental document of the Open Source community
16/04/2017

7. The Open Source Definition
Free Redistribution
Source Code Distribution
Derived Works Allowed
Integrity of The Author's Source Code
No Discrimination Against Persons or Groups
No Discrimination Against Fields of Endeavor
License Must Not Restrict Other Software
License Must Be Technology-Neutral
16/04/2017

8. Open Source Products Operating System Internet Programming Tools Linux
BSDs (Berkeley Systems Distribution of Unix)
Internet
Apache
BIND
Mozilla
Programming Tools
Perl, Zope and PHP: popular engines behind the "live content" on the World Wide Web
The GNU compilers and tools (GCC, Make and others): the most powerful, flexible and extensible set of compilers in the world
16/04/2017

9. Open Source Companies IBM: Use of Apache to support WebSphere, Eclipse
APPLE: Darwin, Quick Time Streaming server
HP: Linux on its servers and handhelds
SUN: Support Java and Mozilla projects
Sharp: Linux on Zaurus handhelds
Red Hat Software: Linux distribution
Open Source in Government and Non-Profit
16/04/2017

10. Summary Open Source and Free Software
Development Process in Open Source
Reasons of Open Source Success
Corporate Source
16/04/2017

11. A new SE paradigm
Technically, OOS (Open Source Software) is defined in terms of distribution licenses, not developmental methods
Intuitively, the development process supported by OSS promises something new to Software Engineering
The principles of OSS development are showing, in a new way, how complex software systems can be constructed, deployed and evolved
16/04/2017

12. Taxonomy of Open Source Development
The term “Open Source Software development” is over-loaded
There are three major focuses:
Archetype: a high quality program as a reference model (GNU software)
Security: software fault-tolerance (PostgreSQL)
Rapidness: rapid adaptation and modification (Linux, excl. kernel)
16/04/2017

13. Open Source Communities
Passive User
Active User
Initiator
Co-developers
Release coordinator
Core team .
16/04/2017

14. Software Engineering Process
The elements of a typical software engineering process are generally enumerated as:
Requirements Analysis
System-Level Design
Detailed Design
Implementation
Integration
Field Testing
Support/Maintenance
16/04/2017

15. Requirements Analysis
Conventional Software:
Create a document which describes the target customers, their reason for needing this product and the list of features of the product
Open Source Software:
Usually Open Source folks tend to build the tools they need
Use of mailing lists or newsgroups
16/04/2017

16. System-level Design Conventional Software:
High-level description of the product, in terms of modules and of the interaction between them
Open Source Software:
There usually is no system-level design
The system design is implicit or it evolves over time
Usually by version 2 or 3 of an open source system, there actually is a system design
16/04/2017

17. Detailed Design Conventional Software:
Every module defined in the system-level design is described in detail
The interfaces of each module has to be determined as well as dependencies between modules
Open Source Software:
Detailed design ends up being a side effect of the implementation
Documenting the API is optional and may not occur if the API isn’t intended to be used outside the project
16/04/2017

18. Implementation Conventional Software:
Every module described in the detailed design has to be implemented
A module can be considered implemented when it has been created and tested
Open Source Software:
This is the fun part
The opportunity to write code is the primary motivation for almost all open source software development efforts
Review is informal
No unit test
16/04/2017

19. Integration Conventional Software:
When all modules are complete, system-level integration can be done
All modules are compiled, linked and packaged as a system
It usually includes the development of a system-level test
Open Source Software:
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
16/04/2017

20. Field Testing Conventional Software:
Field testing usually begins internally (from employees of the organization)
Then, it will be necessary to run the software esternally (on customers’ computer)
Open Source Software:
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
Real world experience of real users
“peer review” of hundreds of other programmers
16/04/2017

21. Support and Maintenance
Conventional Software:
Sofware defects are recorded in a tracking system
These defects are assigned to a software engineer who will propose a change to either the documentation or the implementation
Open Source Software:
When a user finds a bug he can report it an a mailing list, or also send a patch
Sometimes this phase is provided under some payment
16/04/2017

22. Configuration Management
Conventional change process
Change process for OSS
16/04/2017

23. Summary Open Source and Free Software
Development Process in Open Source
Reasons of Open Source Success
Corporate Source
16/04/2017

24. Reasons of Open Source Success
From an end-user perspective:
reduces the cost of software acquisition
enables diversity
simplify collaboration
From a software process and productivity perspective:
Enlarging the user community
Scalable division of labor
Short feedback loops
Greater oppotunity for analysis
16/04/2017

25. Why do developers contribute to Open Source Projects?
Personal needs
Enjoyment
Desire to be part of a team
Reputation
Money
16/04/2017

26. Where OS Succeeds and Fails
Successful domains
Communities with unmet software needs
Technically sophisticated user community
General-purpose, commoditized, infrastructure software
Unsuccessful domains
Highly vertical domains
Highly competitive domains
Highly secure domains
High-confidence domains
16/04/2017

27. Summary Open Source and Free Software
Development Process in Open Source
Reasons of Open Source Success
Successful and Unsuccessful Domains
Corporate Source
16/04/2017

28. Corporate Source: OS Concepts to a Corporate Environment
Corporate Source is the application of OS concepts and methodologies within the corporate envirorment
“Open” to all developers behind the firewall
Community size is smaller than the Internet
16/04/2017

29. Why is Corporate Source good?
Quality
Programmers write better code for sharing vs. just execution
Code Sharing
Corporate Source will promote greater sharing of code among different projects
Maintenance
Bugs get fixed faster, and features added faster, if more people understand and can modify code
‘Bit Rot’ Protection
Prevent code from ‘bit rot’
Intellectual Property
Code is IP that must be protected and widely utilized
16/04/2017

30. References Open Source Initiative - www.opensource.org
GNU project and FSF -
Institute for Software Research -
AICA group -
“Open Sources: Voices from the Open Source Revolution”, edited by DiBona, Ockman, Stone, 1st Edition January 1999
“Understanding the Requirements for Developing Open Source Software Systems”, Walt Scacchi - Institute for Software Research, University of California, Irvine
“Making Sense of the Bazaar”: 1st Workshop on Open Source Software Engineering” -
“Meeting Challenges and Surviving Success”: 2nd Workshop on Open Source Software Engineering -
16/04/2017

31. References
“Taking Stock of the Bazaar”: 3rd Workshop on Open Source Software Engineering
“Leveraging Open-Source Communities To Improve the Quality & Performance of Open-Source Software” – Schmidt, Porter (2001)
“Taxonomy of Open Source Software Development” – Nakakoji, Yamamoto (2001)
“Configuration Management for Open Source Software” – Asklund, Bendix (2001)
“Corporate Source: Applaying Open Source Concepts to a Corporate Environment”- Dinkelacker, Garg (2001)
“Why Do Developers Contribute to Open Source Projects? First Evidence of Economic Incentives – Hann, Roberts, Slaughter (2001)
16/04/2017