Open Source for developers

by Stuart Yeates on 1 July 2004

Introduction

Open Source for developers Stuart Yeates JISC Open Source Software Advisory Service July 2004

Approaches to Open Source Software

Full
Develop as open source and license as open source
Short cut
Develop as you ``normally’’ do and license as open source

Short Cut

  • All of the costs
  • None of the technical benefits
  • Some of the marketing benefits?

No retraining of staff necessary?

Full

  • Release early, release often
  • Distributed development
  • Version control
  • Testing
  • Documentation
  • Open standards
  • Intellectual Property Rights
  • Branding
  • Control

On-going professional development necessary

Release early, release often

  • Encourages communication and openness
  • Continuous flow of feedback on features and progress
  • Opportunities for 3rd party contribution (code, docs, scripts, translations, images, branding, help text, FAQs, …)
  • Small incremental milestones
  • ToDo / Done files (developer rewards)
  • Credits file (contributor rewards)

Distributed development

  • Make it easy for someone to install the software
  • Make it easy for someone to report their problems
  • Make it easy for someone to send a two line fix

Because without these nothing else will work

Version control

What has changed? when did it change? who changed it? why? did it fix that bug?

  • Coordinate the changes from contributors
  • Used to generate changes files
  • Remote / Backup issues
  • Many systems: CVS, SubVersion, Arch, BitKeeper, SourceSafe…
  • SourceForge offers this as a service

Testing

  • Build confidence with developers you may never have met
  • Ensure that bugs are fixed and stay fixed
  • Get your software working exotic hardware and software platforms
  • Prevent changes from fixing sub-systems you’ve never heard of
  • Unit testing, regression testing, random testing, …

Documentation

  • A HowTo to get your software compiled and installed
  • A structured method for users contribute experiences
  • Mailing list, wiki, forums, …
  • The power of searching

Open Standards (1)

  • Open standards allow the smallest amount of code to achieve the most by leveraging other packages.
  • Inter-operability
  • Enable reuse by and of your project

Open Standards (2)

Standards are the basis of robust testing:

  • Data input
  • Data output
  • XML / HTML / CSS / P3P / Accessibility / P3P / RSS / RDF (Checky)
  • Paranoid compiler settings (-pedantic)
  • Translation systems
  • Portability
  • Web load testing

Intellectual Property Rights

  • Track who did what and when (version control)
  • Track employment status
  • Get management to sign of on the release of IPR
  • Write into funding contracts if at all possible

Branding

  • Important for public relations
  • Trademarks very useful
  • Often of great person and emotional importance to software creators

Control

How do I keep control of the software after releasing it as open source?

  • Be the best
  • Invest the most resources
  • Facilitate
  • Persuade

If you stop investing time, resources and expertise in the project it will either die or another leader will emerge.

F/OSS group style creation characteristics (1)

Free and open source software tends to have the following positive development characteristics:

  • Programmer commitment, because the programmer is also the user
  • Rapid change, because programmers want to see results
  • Unconstrained specifications, because there is no external client
  • Collective ownership of code
  • Response to change, dictated by (perhaps unexpected) users

F/OSS group style creation characteristics (2)

… and the following negative characteristics:

  • Unrealistic expectations, because there is no client controlling the specification
  • Uneven development rates, because programmers work on what they want
  • Flat managerial tree, because programmers are not working to contract, so no control or direction
  • Changing resources (no guarantee of work hours)
  • Possibly conflicting goals or aspirations
  • It does not have to succeed_a bit like a rock band?_

F/OSS group style creation characteristics (3)

But the following do not necessarily apply:

  • Poor quality code: likely or as unlikely as in traditional programming
  • Slow development: depends on who takes an interest, how hard they work and what skills they have
  • It isn’t as polished as commercial software: much commercial software is riddled with problems
  • No-one supports it: most projects have a large group of hangers on who do not directly develop, but do help others