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 mannero No royalty to the authoro 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 surviveOSS 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 modelRequirement analysis may be very ad-hocSuccessful projects start with:

VisionPrototype, embodying the visionPreferred mode of communication with community

Community grows, list of requirements growsAdditional requirements may come from anyoneNew 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 postponeRequirements tradeoffs in OSS projects:

Developer community has a sayCore group of developers make these choices Core group takes on the role of system architectCore 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, expensiveSpecial 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