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