Transcript Open Source Software Engineering

Open Source
Software Engineering
Luca Pastorino
17/07/2015
1
Summary
 Open Source and Free Software
 Development Process in Open Source
 Reasons of Open Source Success
 Corporate Source
17/07/2015
2
Summary
 Open Source and Free Software
 Development Process in Open Source
 Reasons of Open Source Success
 Corporate Source
17/07/2015
3
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
1.
to run the program
2.
to study how the program works
3.
to redistribute copies
4.
to modify and improve the program
Open Source

17/07/2015
source code must be open and readable for practical
reasons: it is a development method
4
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

17/07/2015
Promoting the development and use of free
software, particularly the GNU Operating
System
5
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


17/07/2015
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
6
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
6. No Discrimination Against Fields of
Endeavor
7. License Must Not Restrict Other Software
8. License Must Be Technology-Neutral
1.
2.
3.
4.
5.
17/07/2015
7
Open Source Products
 Operating System
 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
17/07/2015
8
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
17/07/2015
9
Summary
 Open Source and Free Software
 Development Process in Open Source
 Reasons of Open Source Success
 Corporate Source
17/07/2015
10
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
17/07/2015
11
Taxonomy of Open Source
Development
 The term “Open Source Software development”
is over-loaded
 There are three major focuses:



17/07/2015
Archetype: a high quality program as a
reference model (GNU software)
Security: software fault-tolerance (PostgreSQL)
Rapidness: rapid adaptation and modification
(Linux, excl. kernel)
12
Open Source Communities
Passive User
Active User
Initiator
Co-developers
Core team
Release
coordinator
.
17/07/2015
13
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
17/07/2015
14
Requirements Analysis
Conventional Software:
Open Source Software:
 Create a document
 Usually Open Source
which describes the
target customers, their
reason for needing this
product and the list of
features of the product
17/07/2015
folks tend to build the
tools they need
 Use of mailing lists or
newsgroups
15
System-level Design
Conventional Software:
Open Source Software:
 High-level description of
 There usually is no
the product, in terms of
modules and of the
interaction between
them
17/07/2015
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
Detailed Design
Conventional Software:
Open Source Software:
 Every module defined in
 Detailed design ends up
the system-level design
is described in detail
 The interfaces of each
module has to be
determined as well as
dependencies between
modules
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
17/07/2015
17
Implementation
Conventional Software:
Open Source Software:
 Every module described
 This is the fun part
in the detailed design
has to be implemented
 A module can be
considered
implemented when it
has been created and
tested
 The opportunity to write
17/07/2015
code is the primary
motivation for almost all
open source software
development efforts
 Review is informal
 No unit test
18
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
17/07/2015
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
19
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)
17/07/2015
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
20
Support and Maintenance
Conventional Software:
Open Source Software:
 Sofware defects are
 When a user finds a
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
17/07/2015
bug he can report it an
a mailing list, or also
send a patch
 Sometimes this phase
is provided under some
payment
21
Configuration Management
Conventional change process
17/07/2015
Change process for OSS
22
Summary
 Open Source and Free Software
 Development Process in Open Source
 Reasons of Open Source Success
 Corporate Source
17/07/2015
23
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
17/07/2015
24
Why do developers contribute to
Open Source Projects?
 Personal needs
 Enjoyment
 Desire to be part of a team
 Reputation
 Money
17/07/2015
25
Where OS Succeeds and Fails
Successful domains
Unsuccessful domains
 Communities with
 Highly vertical domains
unmet software needs
 Technically
sophisticated user
community
 General-purpose,
commoditized,
infrastructure software
 Highly competitive
17/07/2015
domains
 Highly secure domains
 High-confidence
domains
26
Summary
 Open Source and Free Software
 Development Process in Open Source
 Reasons of Open Source Success
 Successful and Unsuccessful Domains
 Corporate Source
17/07/2015
27
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
17/07/2015
28
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





17/07/2015
29
References
 Open Source Initiative - www.opensource.org
 GNU project and FSF - www.gnu.org
 Institute for Software Research - www.isr.uci.edu/research




open-source.html
AICA group - http://linfe.it/
“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” - http://opensource.ucc.ie/icse2001/
“Meeting Challenges and Surviving Success”: 2nd Workshop on
Open Source Software Engineering http://opensource.ucc.ie/icse2002/
17/07/2015
30
References
 “Taking Stock of the Bazaar”: 3rd Workshop on Open Source





Software Engineering http://opensource.ucc.ie/icse2003/
“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)
17/07/2015
31