CSE 2102: Introduction to Software Engineering
Open Source and Free Software: An Overview
Prof. Swapna Gokhale
What is open source/free software?
 Software products distributed with terms so that users can:
o Use, modify, redistribute in any manner
o No royalty to the author
o Preserves the “moral right” of the author to be identified
 Open source vs. free software:
 Different definitions, but practically essential.
 Freedom or liberty to modify the source code, not free as in no
cost – Freedom of speech not free lunch!
 Famous OSS systems:
 Apache & Mozilla Web browsers, Linux Operating System, PHP
programming language, OpenOffice Productivity Suite, GNU
 Revolutionary software development paradigm
 Stiff competitor to proprietary or “closed source” software
Evolution of open source/free software
 Cooperation and sharing -- basic underlying human behavior
 First era – early 1960s to early 1980s
 Key aspects of operating systems and Internet developed at
MIT, Berkley, Bell Labs and Xerox PARC
 Programmers shared basic operating code, and innovations at
various sites.
 Second Era – early 1980s to early 1990s
 AT&T began enforcing its rights
 Formation of Free Software Foundation
 GNU – General Public License, developers must make the source
code freely available.
 Users also must not impose restrictions on others
Evolution of open source/free software
 Third era – early 1990s to today :
 Rapid acceleration of open source activity
 Development of Linux
 Interactions between open source and commercial communities
 Different ways of licensing (imposing different restrictions)
 Where Does Java Fit into this Picture?
 Do you know History of Java?
 Sun Workstations (largest at one time)
 Developed in 1991 by James Gosling
 Released in 1995 with Inclusion into Netscape
 Attempt by Microsoft to Create Own Version (Blocked)
 Sun stopped Making Workstations (became Software Company)
 Oracle Purchased Sun
Who contributes?
 Skewed contributors to development:
 Most contributors make only one contribution
 Top two decile of contributors contribute about 81%
 Even more skewed contributors to bug fixing:
 Every individual contributing code, five report bugs
 “Elitist” open source process:
 Few important contributors, ascend to “core” group
 Many contributors are from outside major software
development organizations
 Nearly 1.1 million people in North America
How to contribute to OS/FS?
 User-oriented contributions:




Providing feedback
Helping new users
Recommending the project to others
Requesting new features
 Product-oriented contributions:
 Testing and reporting or fixing bugs
 Writing and updating software
 Other types of contributions:
 Creating artwork
 Writing or updating documentation
 Translating
What motivates hackers? – Study I
 Intrinsic motivation:
 Inherent satisfaction, not tangible compensation
 Doing for the “fun of it”, enjoying the challenge
 Enjoyment-based intrinsic motivation (“State of flow”) :





Maximum enjoyment
Intense focus and concentration
Enjoying the activity regardless of the outcome
Skills must match the challenge
Sense of creativity
 Obligation/community-based intrinsic motivation:
 Strong sense of community and acting according to the norms
of the group
 “Hacker” culture – having fun while programming, and sharing
code
What motivates hackers? – Study I (contd..)
 Extrinsic motivation:
 Benefit applied from the outside
 Immediate and delayed payoffs
 Immediate payoffs:
 Paid to participate
 Satisfying their particular need
 Firms might hire programmers to participate in OSS
 Delayed benefits:
 Career advancement
 Improving programming skills
 Intense code review by peers
What motivates hackers? – Study II
 Social/community motives (60%):
 Learn and develop new skills
 Share knowledge and skills
 Participate in a new movement/revolution
 Career or monetary concerns (60%):




Improve OS/FS products of other developers
Improve job opportunities
Earn reputation in OS community
Developing, supporting, administrating OSS
 Political motives (65%):
 View software companies as “evil”, and limit their power
 Purely product-related motives (40%):
 Solve a problem that proprietary software cannot solve
 Get help in converting a good idea to a product
Incentives – Open source vs. commercial
 Short-term compensation:
 Commercial organizations can provide salary to programmers
 Programmers working on open source projects have lower costs
– familiarity, effort can also produce private benefit.
 Delayed reward (career advancement, signaling):
 Better performance assessment
 Full initiative – open source programmers are solely responsible,
commercial programmers ‘ performance depends on their boss,
 Greater fluidity:
 Greater flexibility to shift from one project to other
 Open source experience favorable for securing venture
capital:
 Founders of Sun, Netscape, Red Hat signaled their talent in the
open source world
Skills learned – Technical skills
 Algorithmic skills:
 Create new algorithms
 Handling code:




Document code
Design modular code
Write code in a way it can be reused
Reuse code written by the others
 Programming skills:
 Become familiar with different programming languages
 Basic and introductory programming skills
 General skills:
 Look for and fix bugs
 Run and maintain complex software systems
Skills learned – Management skills
 Personal communication skills:
 Clearly articulate an argument
 Express personal opinions
 Accept and respond to criticism from others
 Planning skills:
 Clearly define and achieve targets
 Plan work and stick to a schedule
 Group and team skills:





Coordinate one’s work with work of the others
Evaluate the work of others
Lead a project or a group of people
Settle conflicts within a group
Motivate people
Skills learned – Legal skills
 Understand the various forms of intellectual property:
 Patents, copyrights, trademarks
 Different types of licenses :
 What each license allows and does not allow
 Liability issues
 What Potentially can Go Wrong?
 What Situations Does Use of OSS Have Concerns?
 What Kind of Software not Appropriate for OSS?
Skills learned – General skills
 Language skills:
 Understand English
 Technical discussions
 Overview of documents in software technology
 Interpersonal skills:
 Understand and work with people from different cultures
 Interact with other people
OSS vs. commercial software
 Market share:





Software considered successful -- large marketshare
Apache (open source) vs. IIS (proprietary)
Linux is #2 OS used in web server
Linux as popular as Windows for applications development
More companies adopting OSS to control software costs
 Higher reliability:
 OSS has higher reliability than commercial software
 Bugs not fixed in commercial software, but fixed in OSS
 Linux more reliable than Windows, Apache more reliable than
IIS
OSS vs. commercial software
 Performance:
 Linux has better performance than Windows
 Scalability:
 Linux dominates in the world of supercomputing
 What Underlies Andriod?
 Security:
 Most compromised sites are run by Windows
 Unpatched Linux systems are better than unpatched Windows
 Apache has better track record than IIS
 Total cost of ownership:
 OSS costs less than commercial software
 Includes costs involved in the overall lifespan of the software –
initial purchase price, licensing costs, training costs, support
costs, hardware costs, and upgrade costs if any.
What makes a successful open source project?
 Modularity:
 Project should be divisible into small and well-defined tasks.
 Programmers can pursue these tasks without interacting
 Interesting/fun challenges to pursue:
 Exciting problems that need to be solved, attract programmers
 Leadership:
 Credible leader or leadership
 Starts and assembles a critical mass of code, but does less
programming over time.
 Provides the vision
 Attracts programmers
 Keeps the project together – avoids forking or being abandoned
Interface between CS and OS software
 Commercial firms initially dismissed OSS revolution
 Microsoft released “Halloween documents”
 Outlining the potential threat
 Source of great excitement and boost to the OSS movement
 See: http://en.wikipedia.org/wiki/Halloween_Documents
 What do commercial firms do to survive?
 Living symbiotically off of an open source project
 Code release
 Living symbiotically:
 Provide complementary functions and services not efficiently
provided by OSS.
 Red Hat provides “support” for Linux
 Allocate a few programmers to open source projects
 “Reactive strategy”
Interface between CS and OS Software (contd..)
 Code release:
 Release some of its proprietary code
 Sell complementary services, and boost profits – for example,
consulting for a given piece of code
What OSS Does UConn Have?
 Profiles Research Networking Software profiles.uconn.edu
 Developed by Harvard Medical School
 Maintained Version Supported by Recombinant
Where do we find open source software?
 OpenDisc :
 Excellent source of software for Windows PC, Email Client,
Web browser, Office Suite (http://theopendisc.com/)
 Mac Users:
 FreeSMUG suite CD, (http://www.freesmug.org/fscd/)
 PortableApps:
Portable Applications on USB Memory Stick
 LiveCDs :
 Boot an Intel PC using a Linux OS, without installing the OS,
right off of the CD, Ubuntu, Knoppix
 Apache Software Foundation:
 http://www.apache.org
 GNU project – Free Software Foundation:
 www.gnu.org/software/software.html
Where do we find open source software?
 Freshmeat:
 http://www.freesmug.org/fscd/
 Sourceforge:
 http://sourceforge.net/
 W3C Consortium:
 http://www.w3.org/Status.html
 Codeplex:
 http://www.w3.org/Status.html
Literature and resources
 OSS Watch – Open Source Software Advisory Service:
 http://www.oss-watch.ac.uk/
 Perspectives on Free and Open Source Software, Joseph
Feller, Brian Fitzgerald, Scott A. Hissam, and Karim R.
Lakhani
 http://www.dwheeler.com/oss_fs_why.html and the
references therein
 http://www.flossproject.org
OSS and software qualities
Performance and reliability requirements of OSS are similar to
proprietary systems:
Depend on the domain of the system
Security – OSS is better :
Many eyes viewing the software, can identify bugs that
compromise the system
Security – OSS is worse:
Security through obscurity
Secrecy of the source code is better
Usability:
Users have a chance to provide feedback early and often
Sometimes developers themselves are users
24
OSS and software qualities
Maintainability, understandability, evolvability, and repairability
are very important:
OSS are in continuous state of evolution
Verifability:
Desirable, but difficult to achieve.
Some OSSs have test suites, some don’t
25
OSS and principles
Rigor and formality:
Difficult to find rigorous and formal requirements for OSS.
Projects usually start to fulfill someone’s needs.
Anticipation of change, Incrementality – OSS follows the
principle of “release early and often”
Functionality is developed incrementally, as the needs of the users
change
OSS projects evolve continuously
Generality:
Usually, OSS projects fulfill specific needs
Difficult to find something that’s general
26
OSS and principles
Modularity -- most important principle for the success of a
OSS project.
Project divided into small and well-defined tasks
Programmers should be able to pursue these tasks without
interacting
27
OSS and software design
OSS projects may not undergo a conscious design process:
Most projects start off because to fulfill someone’s need.
Yet, only the well-designed, modular projects survive
OSS products should exhibit:
High cohesion
Low coupling
Design may or may not be well documented
Reverse engineer the design of your chosen OSS project.
28
OSS and requirements
OSS model may differ from the traditional model
Requirement analysis may be very ad-hoc
Successful projects start with:
Vision
Prototype, embodying the vision
Preferred mode of communication with community
Community grows, list of requirements grows
Additional requirements may come from anyone
New requirements may be presented as a full-fledged
implementation
29
OSS and requirements (contd..)
Requirements tradeoffs in traditional projects:
Architect weighs conflicts and decides which to
incorporate and which to postpone
Requirements tradeoffs in OSS projects:
Developer community has a say
Core group of developers make these choices
Core group takes on the role of system architect
Core group is respected, process is same as traditional
project
30
OSS and testing (Apache server)
Pre-release/pre-commit testing:
Developer makes changes to the local copy
Tests on his or her own server
Comparable to unit test, thoroughness of the test depends on
judgment and expertise of the developer
No additional testing required prior to release
Review may be required before committing
Don’t break the build
Inspections:
Commit the change directly
Produces a patch and mails it to developer list for review
Changes to stable release – review before commit
Changes to development release – review after commit
Commit generally by the originator
31
OSS and software process models
OSS projects go through all the steps:
Iteration possible at each step
Sequencing may be different
Requirements analysis may be ad-hoc:
Successful projects start with a vision
Artifact, that embodies the vision
Preferred way of communicating top-level requirements with OSS
community
List of possible requirements grows with community:
Additional requirements, new features from anybody
Sometimes may be presented as implementation
32
OSS and software process models (contd..)
Resolving conflicts among requirements:
Traditional: System architect resolves conflicts
OSS: Developer community may vote
Successful OSS projects, core group of respected developers to
make choices
Core group can have the same effect as system architect
Implementation and testing:
Similar to traditional projects, parallel with specification
Individual developers are powerful:
Carve out niche, free to design, implement, test as they see fit
Competing designs and implementations, one will be selected
Core group makes the selection
33
OSS and process models (contd..)
Maintenance, upgrade, release or porting:
OSS projects rely on tools
Version control, bug tracking, documentation, maintenance and
distributed development
OSS project that does not use sophisticated tools:
Too small, or will eventually fail
34
OSS and cost estimation models
Existing estimation models cannot be used with OSS projects:
Data collected from commercial CSS projects
OSS projects have different platform and tools
Existing data from long-term new projects, rather than
maintenance projects
OSS projects are maintenance-centric
Issues in developing estimation models for OSS:
Skewed effort by participants
Participants do not keep track of the time expended
Collaboration among geographically disperse participants
Effort should be estimated on code changed, or any other metric?
35
OSS and SE tools
Traditional projects not open to adopting SE tools:
Do not fit the day-to-day needs
Difficult to use, expensive
Special purpose
Successful OSS projects rapidly adopt SE tools:
Many tools continue to be developed – issue tracking, code
generation, automated testing, document generation,
packaging
Tools promote OSS practices (http://tigris.org)
One of the most important tools is configuration
management.
36