Open Source for managers

by Sebastian Rahtz on 1 July 2004

Introduction

Open Source for managers Sebastian Rahtz JISC Open Source Software Advisory Service July 2004

Our programme today

Let’s talk about:

  • Why open source is undermining decent software
  • Why open source folks just steal good ideas and make monkey copies
  • Why open source software is full of bugs and security loopholes
  • Why it is always best go with a single large provider of software
  • Why Microsoft Word is a standard
  • Why you can’t trust stuff written by Russian teenagers

Real Objectives

  • Give an overview of what it means to develop software as open source.
  • Explain the different approaches to open source development.

  • Give a brief overview of open source licensing. The intended outcomes are to:

  • Ensure that all projects understand the impact that an open source development plan can have on project management.
  • Ensure that projects know where to find advice and guidance as they develop open source software.
  • Ensure that all projects understand the requirements and responsibilities of using / developing open source.

What is OSS Watch?

We are here to advise UK HE/FE about issues around open source software:

  • funded by JISC for two years from 1st July 2003
  • part of JISC’s Information Environment
  • working in partnership with other JISC services, eg CETIS and the Mirror Service
  • serving FE and HE equally (not just research universities)
  • visible at http://www.oss-watch.ac.uk We have a staff of 1.25 FTE, comprising one manager (0.25), one communicator (0.5) and two researchers (0.2 and 0.3).

What OSS Watch does

  • Offers a neutral and practical web site
  • Runs at least two open meetings a year
  • Runs two focus groups year, and writes analyses
  • Engages in understanding institutional processes
  • Advises IT managers, project developers, and users
  • Gives advice on open source at any UK/FE forum — and makes all its material available under the GNU Free Documentation License

What OSS Watch does not do

  • Try to persuade people to adopt open source
  • Run a software repository
  • Help people with their Open Office problems
  • Compete with FLOSSIE, freshmeat, slashdot etc
  • Provide definitive legal advice
  • Be a debating forum for hairy sandal-wearing geeks

Questions we might answer today

  • What is free/open source software?
  • How does it relate to software engineering?
  • Does free/open source imply a mode of programming?
  • Do free/open source methodologies develop from, turn into, or co-exist with changes in software engineering?
  • What work practices can help the JISC framework programme?
  • What must the JISC mandate to get good results?

Depending on your viewpoint

The debate about free/libre/open source software is:

  • Just politics, it’ll go away
  • A legal and cultural affair, which will take years to follow through
  • A matter of software engineering
  • Just trivia for sandal-wearing bigots to worry about

Technically, what does Open Source mean?

Software for which:

  • the source code is available to the end-user;
  • the source code can be modified by the end-user;
  • there are no restrictions on redistribution or use;
  • the licensing conditions are usually intended to _facilitate _ continued re-use and wide availability of the software, in both commercial and non-commercial contexts;
  • the cost of acquisition to the end-user is often minimal.Open Source is a development methodology; Free Software is a social movement.

FLOSS?

In English, free has two meanings in one word, whereas the French distinguish libre and gratuit. Many practioners use the shorthand FLOSS (FreeLibre Open Source Software)

Virtues of free and open source software

  • has no secrets: the innards are available for anyone to inspect
  • is not privately controlled: so likely to promote open rather than proprietary formats
  • is typically maintained by communities rather than corporations: so bug fixes and enhancement are often frequent and free
  • is usually distributed free of charge (developers make their money from support, training, customisation and specialist add-ons; not marketing)

Clearing up misunderstandings

  • Free software uses the free from freedom, not the one from free beer. Open source software may or may not cost money
  • The cost of ownership often bears little relation to the cost of acquiring a piece of software
  • Public domain is something different. Open source software has a copyright holder and conditions of legal use
  • Open source software does not mandate exclusivity. You can use open source programs under Windows (TheOpenCD)
  • People do not choose software solely on the basis of open source. Interoperability and open standards for data are equally important

An open source guidance framework

Some of the areas in which JISC needs to provide guidance:

  • IPR Ownership
  • Licensing
  • Trademarks
  • Software Development communities
    • Software Dependencies
    • Storage
    • Quality assurance
    • Version Control
    • Sustainability
    • Documentation
    • Open Standards The starred items are addressed in our other session

IPR Ownership

Software is property. In law, property belongs to your employer unless your contract explicitly says not. The documentation for your software is part of its design, and is property too.

Copyright ownership of software documentation, manuals, user interface and source code must be recorded, may be vested with a JISC-appointed body and should be released under an OSI-compliant open source licence. It must be licensed and publicly available at zero financial cost throughout UK higher and further education.

The ownership of code developed in joint projects must be established before work begins.

Why divest yourself of IPR?

There are three good reasons for giving copyright to a neutral third party:

  • Many projects are partnerships between several educational institutions and commercial companies. It is often hard to record where precisely property has been created.
  • Small businesses or educational establishments do not have the resources to pursue legal claims. Don’t make claims you are not prepared to back up!
  • The copyright owner is not bound by the licence. A university can release version 1 under the GPL, but commercialize version 2. If the sources is notionally licensed from a third party, it keeps them honest.

Some software history

In the beginning (well, 30 years ago):

  • Hardware cost serious money
  • Operating system software was usually patched locally
  • Application software was thin on the ground
  • Users were highly computer-literate and were expected to develop their own programs so who cared about whether software was free?

…and then we had the PC revolution…

  • Desktop computers had to be sold cheaply
  • Ordinary people got computers
  • Some clever folks wrote killer applications
  • Bill Gates saw the value of a standard operating system and lo! a market was created and all was well in the world.

Well, almost

  • people got greedy and wanted free software
  • some big companies woke up to the value of the assets they had previously given away
  • a community of amateur programmers was unleashed on the world
  • a few people realized that there was a danger of being locked out of developments entirely

Red herrings

We had a curious interregnum where:

  • Lots of people stole (pirated) software
  • Some people tried selling on trust (shareware)
  • Other people thought public domain would solve everything
  • Yet other people thought a vague don’t use it to make money or war condition would be binding but now we have largely settled into a stable mixed economy.

Typical licensing issues

  • you must (sometimes) redistribute the software intact with source code
  • if you integrate it with your own system and then redistribute that, your software may be covered by the licence too
  • most OSS licences are perpetual but the author is not bound to release revised versions under the licence
  • if you do not submit patches back to the original, expect to have maintenance issues in the future, particularly when security patches are released
  • your patches are copyrighted works in themselves, and licensing issues apply to them

Licensing

The three basic licence models:
GPL
If you extend a GPL program, or create a composite with it, you cannot release your work except under the GPL and must offer the source code to the full program to everyone you give the program to
LGPL
If you extend an LGPL program, as with GPL. If you create composites with LGPL code you must offer the source code of the LGPL portion, but may retain the source code to your portions
BSD
You must continue to display the copyright notice on any derived work

If a system is built of two parts eg communicating via SOAP, they are considered separate programs.

What about Creative Commons?

This is not about open source, but about simplifying the licensing of creative work in general, and encouraging the release of artistic works under liberal licences.

The CC range of licences covers areas (eg licensing for non-commercial user) which are incompatible with Open Source.

http://creativecommons.org/

The GNU licence question

50-80% of OSS uses the GNU General Public License.

The GPL does not require you to release your modified version.

  • You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization.
  • If you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program’s users, under the GPL. Thus, the GPL gives permission to release the modified program in certain ways, and not in other ways; but the decision of whether to release it is up to you.

GPL urban myths exploded

  • You can sell GPLed programs with no problem
  • You can sell support, training and certification for GPL programs
  • The GPL does not apply to things you create with GPLed tools
  • You can change the programs and keep the changes to yourself; so long as you don’t distribute them
  • GPL software does not have any stamp of approval or follow any special standards
  • The copyright owner is not bound by the licence

Does the GPL limit you?

It limits you if plan to make money selling modified versions of GPL programs, or incorporate them into your own.

But many people make a living from GPLed software.

You can work around the GPL by:

  • writing wrapper software
  • decoupling your software by by defining a domain-specific language and implementing that separately.

Companies mixing OSS with business

  • MySQL
  • RedHat
  • IBM
  • Sun
  • Novell (now also owners of SuSe)
  • Apple
  • …and many small independent consultants All these see a place for licensing some software under open source terms as part of their business.

What about dual licensing?

Some companies offer their software under more than one licence. MySQL is a good example. They are a reasonable-sized company with three main sources of revenue:

  • Online support and subscription services sold globally over the MySQL.com website to all users of the MySQL server.
  • Sales of commercial MySQL licences to users and developers of software products and of products that contain software.
  • Franchise of MySQL products and services under the MySQL brand to value-added partners. MySQL is available under GPL or commercial licence

Licence conclusion

Use a simple, well-understood licence. Unless you have a free lawyer, don’t try to write your own. We believe that the LGPL licence is the best for toolkits, primarily because it involves an ongoing relationship between the original authors and the subsequent developer community.

The BSD-like licences are more one-sided, allowing for unlimited use by everyone, but less protection for the community.

Do not try to limit your licence to the UK educational community. You will cut yourself off from distributions and developers. You will not be open source.

Trademarks

The JISC will make no claim to trademarks. Projects are encouraged to trademark their brands to build their reputations, and provide a route to exploitation of their knowledge.

Do not bet your pension on trademark claims unless you have a free lawyer. Trademarking your name draws a line in the sand, showing your intentions; it is not a suit of armour. Trademarks also need registering in other jurisdictions.

A Sense of Community

  • What is the difference between licensing and community?
  • The cathedral vs the bazaar
  • The bazaar model engages user communities
  • The cathedral model is best if you already know everything…

The cathedral and the bazaar

F/OSS projects tend to be classified into two extreme camps:

  • A genius programmer creates something which others like. (S)he controls pace and scope of future development. The genius has a complete idea of what the finished software will look like. Changes to the design during the build process are very costly, but the resulting software very polished and uniform.
  • A group of people get together to fill a gap and take on different tasks. As time goes by, some drift away and others join in. There is always someone to take over. Design is by consensus, with people working on topics that motivate them. Design changes are relatively cheap but with no over-arching the finished program can be patchy. Most projects fall in between. Most of them have a recognised leader, to whom other members defer. A gentle system of leadership challenge and deposition assures the health of the herd is kept up.

Read http://www.catb.org/~esr/writings/cathedral-bazaar/ (Eric Raymond’s The Cathedral and the Bazaar)

Open Source — The Bad News

  • It is not a silver bullet
  • Software engineering laws still apply—The Mythical Man Month is still in print!
  • It doesn’t guarantee hoards of OS hackers to help you
  • It doesn’t guarantee defect-free code

Open Source — The Good News

  • It can reduce the likelihood that software will be abandoned at the end of the project
  • If it takes off, it reduces maintainance load on originators

  • Non-source contributions are also likely:

    • translations (Welsh?)
    • documentation (HowTos)
    • FAQs
    • body of knowledge in the mailing lists (Google)

Environnment: Sourceforge 1

Environnment: Sourceforge 2

Environnment: Sourceforge 3

Example 1: Apache

A charitable consortium which

  • guards IPR
  • sets technical standards
  • encourages related projects which match their interests
  • launders money The core Apache server does not get abused because it is in no-one’s interests to do so.

Example 2: Exim

An individual employed at Cambridge to do good stuff. He

  • decides what and when to release
  • accepts patches
  • may or may not hand over to someone else one day

Example 3: MySQL

The classic dual-licensing system. The MySQL company

  • own the code and the name
  • release it under the GPL to anyone
  • license it for money to people who want to embed it
  • hire the people who understand the code best
  • stream of new programmers come on board from working with the GPL version

Example 4: Bodington

The cottage industry example

  • built up from personal code
  • going into Sourceforge slowly
  • not very well documented
  • building a community post hoc

Example 5: OpenOffice

The classic big brother project

  • Core is developed by Sun programmers
  • XML format defined by OASIS
  • Interested groups work on extensions
  • Open sourceness largely theoretical. Free beer and open file formats is much more important!

Example 6: Text Encoding Initiative

OSS is not just about programming. The TEI defines guidelines for marking up text.

  • Very traditional cathedral model with closed licence
  • Now switching to open source licence (GPL) and public development on Sourceforge
  • Facing a major cultural shift for all concerned The TEI move is largely driven by a desire to be distributed and used widely.

Example 7: Urchin

The JISC-funded open source project to do RSS aggregation

  • Copyright (C) Higher Education Funding Council for England (HEFCE)
  • Lives on Sourceforge
  • Ongoing engagement with RDF research community
  • Provides toolkit and some tools
  • Waiting to be packaged…still nerd-oriented

Example 8: TeX

The story from hell. A very well-respected academic writes a typesetting system. You can do what you like with it, but if you call it TeX it must always produce the same result.

  • the devil and deep blue sea: you can put a changed version out under another name, but then no-one knows what it is
  • the owner of the copyright has no interest in change, but would not release copyright
  • there is an accretion of associated software which has no overall direction
  • users groups set standards for themselves but cannot enforce them But it remains in widespread use.

Studying Open Source

The FLOSS study (http://www.infonomics.nl/FLOSS/) is the best known of a series of studies by economists on how FLOSS works.

There is a big archive of papers att http://opensource.mit.edu

The informal data in following slides is derived from presentatons at the Oxford Internet Institute workshop on open source, June 2004.

Why do people join open source projects?

The studies show that people join an open source project because

  • it looks like important project: 30%
  • it looks technically interesting: 40%
  • they know other people involved: 17%
  • it solves a problem they have: 35%

Why do people keep working on open source?

The desire to learn technical skills by joining an open project is strong. Typical reasons for staying in OSS are:

  • seeking recognition: 12%
  • improving skills: 32%
  • improving software: 24%
  • ideology 31%

How do companies work in open source?

  • implementation of open standards might as well be done in a shared way to save costs
  • pyramidal consulting works: making software means that your support team are shared the 80% of questions which easy, leaving your the remaining 20%
  • needed improvement funding to open source ie economically efficient. Work on the things you care about
  • the revenue margin on licences is 85%, on support 54%; eg IBM and Novell are now depending more on services than licensing

Summary

  • open source is a fixed legal position, not an attitude
  • licensing is orthogonal to development methodology
  • community development works
  • open source licensing is compatible with doing business