Bringing open source
to Ohio campuses:
Meeting common goals through shared solutions

Scott E. Siddall

Denison University

This presentation at http://siddall.info/talks/

Roadmap

What is open source software?

The culture of open source

Leadership of open source projects

The common needs of education

Build-Buy-Borrow

Build your own?

Bear all the development costs

Provide all your own support

Buy?

Share development costs with others, plus a vendor profit

Pay for support from vendor

Borrow (open source)?

No licensing costs, or share the costs

Provide your own support, buy it, get it from the community

Open source is a licensing model

Open Source Initiative

55 licensing models

GNU Public License (GPL) applies to 40,000 projects at Sourceforge

GPL, BSD, Mozilla, MIT are all popular

Slide 5

Open source is more than a licensing model

“When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.”

The Open Source Initiative http://opensource.org

Types of open source software

Central services and infrastructure

Email systems, servers, network management tools

Desktop operating systems

Linux, Sun Java Desktop

Web applications

ePortfolios, portals, course management, digital asset management, collaboration and communication tools

“Open source is moving up the stack”

- Brad Wheeler, Indiana University

Contentions

OSS costs less than proprietary software

OSS licensing is easy

OSS is more reliable, fewer bugs

OSS can be customized

OSS is more secure

OSS is better because it uses open standards

OSS is by and for a community

Proprietary software has better support

OSS is difficult to install, distribute, migrate to

OSS avoids vendor lock-in

OSS reuses software elements efficiently

Proprietary software developers have better resources

“The Cathedral and the Bazaar”

Every good work of software starts by scratching a developer's personal itch.

Good programmers know what to write. Great ones know what to rewrite (and reuse).

When you lose interest in a program, your last duty to it is to hand it off to a competent successor.

Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.

Release early. Release often. And listen to your customers.

Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.

The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

- Eric S. Raymond, 1997

The Culture of Open Source

Complex software development

By loosely coordinated developers and contributors

In an informal meritocracy

software specifications are rarely written

continuous design instead

virtual project management

a gentle hierarchy

Need for leadership

“People think just because it is open-source, the result is going to be automatically better. Not true. You have to lead it in the right directions to succeed.”

- Linus Torvalds

Community Source

Purposeful coordination of work within a community

Based on the principles of open source development

A greater reliance on

Defined roles

Responsibilities

Funded commitments

In between the cathedral and the bazaar

Caveat:

production of software versus catalyzing a community

POLL

If your institution confronts obstacles to greater technical innovation, what are they?

A - Resource limitations

B - Culture rooted in traditional processes

C - Aversion to risk

D - Discomfort with change

E - Leadership

F - Other issues….

Is the open source model successful?

“Free and open-source software development is faster, better and cheaper in building a community and at reinforcing and institutionalizing a culture for how to develop software”

Walt Scacchi (2004)

Institute for Software Research

UC Irvine

Our business officers are being encouraged…

Where do our institutions stand?

Most are tracking OSS developments

Most agree: higher education should create software to meet our unique needs

Most see interoperability as important as OSS licensing

Few have any official strategy on OSS

A few don’t use OSS now

Why? Costs, lack of support, no accountability, too busy, immature OSS, no resources to shift to OSS

Where do our institutions stand?

Of 118 respondents that do use open source software:

    73 use open source software for mission critical applications

    66 use open source software in the academic enterprise

    63 have experimental uses of open source outside of

CS/engineering departments

    56 use open source apps and provide feedback to developers

    39 contribute resources toward open source development

    33 have employees that contribute to open source

            development on their own time

    26 have distributed their own homegrown applications

How are they using OSS?

            106 in servers, databases and infrastructure

            82 in desktop operating systems

            61 in curricular or collaborative applications

            26 in desktop and administrative applications

Practical recommendations

Examine the entire cost

Licensing, hardware, support, training, documentation, migration from legacy tools

Ask why you are considering any application

Are learning outcomes the driver?

Pilot the software

Directly involve all stakeholders; consider outsourcing the pilot

Start with “low hanging fruit” – not mission critical applications

Understand and plan for support needs

Spend avoided licensing costs on local staff development

Keep looking – new opportunities arise each week

POLL

Do you feel your institution is ready to undertake a project that relies on open source software?

A – Yes

B – No

C – Don’t know

Future of the software market

We share unique software requirements

Education is a tiny piece of the global software market place

Who will create our software, at what cost?

Will we have to craft our own software?

What will be the impact of software development by for-profit education?

Common needs of education

…..but we have the resources

Learning and research are our core competencies, our products – this is strategic!

IHE are centers of research in software development

A diverse, capable and open community: doctoral/research, masters, baccalaureate, associates, K-12

Consortial piloting in Ohio

Limited scale pilot programs

Fully engage faculty and students as well as technical staff in evaluations

Co-source (partner with a support entity) then focus on learning and teaching

Collaborate: minimize the reinvention of wheels

POLL

How important is it to our institutions that we design and create our own software to support learning?

A – Crucial

B – Important

C – Neutral

D – Unimportant

E – Bad idea

Resources - Articles

"The Cathedral and the Bazaar" by Eric S. Raymond, 1997.

“A Second Look at the Cathedral and Bazaar” by Nikolai Bezroukov, 1999. In First Monday.

Altruistic individuals, selfish firms? The structure of motivation in Open Source software in First Monday by Andrea Bonaccorsi and Cristina Rossi

“Open Source 2007: How did this happen?” by Brad Wheeler

“Open Source CMS Pilots” by Scott Siddall. March, 2004.

“Socio-technical interaction networks” by Walt Scacchi, 2004.

“Using Open Source for Strategic Advantage” by Alfred Essa (EDUCAUSE Live! Session, April 2004)

“Update on Westwood and Chandler for Higher Ed” by Scott Siddall.

An Open Mind on Open Source by Karla Hignite. In NACUBO’s Business Officer magazine, August 2004.

Open Source under the microscope by Paul Festa, 2004. C/NET News.

Universities Offer Homegrown Course Software by Jeffrey Young, July 23, 2004. The Chronicle of Higher Education.

Resources – Web sites

Technical glossary related to open source

Sourceforge - “the" open source software development site listing more than 85,000 open source projects

The Open Source Initiative – promotes the definition of open source

Open source research at the Institute for Software Research, UC Irvine

EDUCAUSE Center for Applied Research research bulletin, “Aligning IT Strategy to Open Source, Partnering and Web Services.” Nov. 2003.

Return to home


	Scott E. Siddall
	Denison University

	This presentation at http://siddall.info/talks/


	What is open source software?
	The culture of open source
	Leadership of open source projects
	The common needs of education


	Build your own?
		Bear all the development costs
		Provide all your own support
	Buy?
		Share development costs with others, plus a vendor profit
		Pay for support from vendor
	Borrow (open source)?
		No licensing costs, or share the costs
		Provide your own support, buy it, get it from the community


	Open Source Initiative
	55 licensing models
	GNU Public License (GPL) applies to 40,000 projects at Sourceforge
	GPL, BSD, Mozilla, MIT are all popular


	“When programmers can read, redistribute, and modify the source code for a piece of software, the software evolves. People improve it, people adapt it, people fix bugs. And this can happen at a speed that, if one is used to the slow pace of conventional software development, seems astonishing.”

		The Open Source Initiative http://opensource.org


	Central services and infrastructure
		Email systems, servers, network management tools
	Desktop operating systems
		Linux, Sun Java Desktop
	Web applications
		ePortfolios, portals, course management, digital asset management, collaboration and communication tools
	“Open source is moving up the stack”
	- Brad Wheeler, Indiana University


	OSS costs less than proprietary software
	OSS licensing is easy
	OSS is more reliable, fewer bugs
	OSS can be customized
	OSS is more secure
	OSS is better because it uses open standards
	OSS is by and for a community
	Proprietary software has better support
	OSS is difficult to install, distribute, migrate to
	OSS avoids vendor lock-in
	OSS reuses software elements efficiently
	Proprietary software developers have better resources


	Every good work of software starts by scratching a developer's personal itch.
	Good programmers know what to write. Great ones know what to rewrite (and reuse).
	When you lose interest in a program, your last duty to it is to hand it off to a competent successor.
	Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging.
	Release early. Release often. And listen to your customers.
	Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
	The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better.

	- Eric S. Raymond, 1997


	Complex software development
	By loosely coordinated developers and contributors
	In an informal meritocracy
		software specifications are rarely written
		continuous design instead
		virtual project management
		a gentle hierarchy


	“People think just because it is open-source, the result is going to be automatically better. Not true. You have to lead it in the right directions to succeed.”
	- Linus Torvalds


	Purposeful coordination of work within a community
	Based on the principles of open source development
	A greater reliance on
		Defined roles
		Responsibilities
		Funded commitments

	In between the cathedral and the bazaar

	Caveat:
		production of software versus catalyzing a community


	If your institution confronts obstacles to greater technical innovation, what are they?

		A - Resource limitations
		B - Culture rooted in traditional processes
		C - Aversion to risk
		D - Discomfort with change
		E - Leadership
		F - Other issues….


	“Free and open-source software development is faster, better and cheaper in building a community and at reinforcing and institutionalizing a culture for how to develop software”

	Walt Scacchi (2004)
	Institute for Software Research
	UC Irvine


	Most are tracking OSS developments
	Most agree: higher education should create software to meet our unique needs
	Most see interoperability as important as OSS licensing
	Few have any official strategy on OSS
	A few don’t use OSS now
		Why? Costs, lack of support, no accountability, too busy, immature OSS, no resources to shift to OSS


	Of 118 respondents that do use open source software:
	73 use open source software for mission critical applications
	66 use open source software in the academic enterprise
	63 have experimental uses of open source outside of
	CS/engineering departments
	56 use open source apps and provide feedback to developers
	39 contribute resources toward open source development
	33 have employees that contribute to open source
	development on their own time
	26 have distributed their own homegrown applications

	How are they using OSS?
	106 in servers, databases and infrastructure
	82 in desktop operating systems
	61 in curricular or collaborative applications
	26 in desktop and administrative applications


	Examine the entire cost
		Licensing, hardware, support, training, documentation, migration from legacy tools
	Ask why you are considering any application
		Are learning outcomes the driver?
	Pilot the software
		Directly involve all stakeholders; consider outsourcing the pilot
	Start with “low hanging fruit” – not mission critical applications
	Understand and plan for support needs
	Spend avoided licensing costs on local staff development
	Keep looking – new opportunities arise each week


	Do you feel your institution is ready to undertake a project that relies on open source software?

		A – Yes
		B – No
		C – Don’t know


	We share unique software requirements
	Education is a tiny piece of the global software market place

	Who will create our software, at what cost?
	Will we have to craft our own software?
	What will be the impact of software development by for-profit education?


	…..but we have the resources

		Learning and research are our core competencies, our products – this is strategic!
		IHE are centers of research in software development
		A diverse, capable and open community: doctoral/research, masters, baccalaureate, associates, K-12


	Fully engage faculty and students as well as technical staff in evaluations
	Co-source (partner with a support entity) then focus on learning and teaching
	Collaborate: minimize the reinvention of wheels


	How important is it to our institutions that we design and create our own software to support learning?

		A – Crucial
		B – Important
		C – Neutral
		D – Unimportant
		E – Bad idea


	"The Cathedral and the Bazaar" by Eric S. Raymond, 1997.
	“A Second Look at the Cathedral and Bazaar” by Nikolai Bezroukov, 1999. In First Monday.
	Altruistic individuals, selfish firms? The structure of motivation in Open Source software in First Monday by Andrea Bonaccorsi and Cristina Rossi
	“Open Source 2007: How did this happen?” by Brad Wheeler
	“Open Source CMS Pilots” by Scott Siddall. March, 2004.
	“Socio-technical interaction networks” by Walt Scacchi, 2004.
	“Using Open Source for Strategic Advantage” by Alfred Essa (EDUCAUSE Live! Session, April 2004)
	“Update on Westwood and Chandler for Higher Ed” by Scott Siddall.
	An Open Mind on Open Source by Karla Hignite. In NACUBO’s Business Officer magazine, August 2004.
	Open Source under the microscope by Paul Festa, 2004. C/NET News.
	Universities Offer Homegrown Course Software by Jeffrey Young, July 23, 2004. The Chronicle of Higher Education.


	Technical glossary related to open source
	Sourceforge - “the" open source software development site listing more than 85,000 open source projects
	The Open Source Initiative – promotes the definition of open source
	Open source research at the Institute for Software Research, UC Irvine
	EDUCAUSE Center for Applied Research research bulletin, “Aligning IT Strategy to Open Source, Partnering and Web Services.” Nov. 2003.