Neil Chie Hong (www.omii.ac.uk) starting off this session talking about “Why good s/w sometimes dies, and how to save it (sometimes)”

Outlining the issue: some researchers produce s/w but don’t care about sustainability – happy for others to take over s/w (subject to IP), others though see sustainability as key, but don’t feel they have skills or resources to ensure s/w has life beyond the creation/development

Question – how do we ensure that s/w which has users can continue to support them? How do we help s/w survive the transition from creation to widespread use?

Neil outlining his background – different sizes of organisations in very different contexts – but always about how do you make the best use of resources to improve takeup of what you already have (e.g. s/w)

Neil talking about ‘long tail‘ and asking whether there is a long tail effect for s/w? Saying libraries benefit from long tail effect. What about an online s/w repository? There is a problem with ‘storage lifespan’ – books have a long shelf life >50 years, but software has a storage lifespan of more like 12 months – after this, the environment (operating systems, drivers, other dependencies) change to the extent that the s/w is no longer viable to run.

The long tail depends on a number of things including ‘negligible stocking and distribution costs’ – but the cost of maintaining software mean that this is not the case for s/w, so the long tail doesn’t apply – it costs money to ‘prevent decay’ so storage costs actually high (much higher than books)

Open source software is ‘free’ as in ‘free puppies’ – needs longterm care, may lose charm after growing up, can end up being abandoned by owners

It is not enough to say your s/w is open source – this doesn’t in anyway guarantee future of s/w. You need a community around it.

Engage project – from interviews, reasons for using a specific piece of s/w.
People prioritise:

• Ease of use
• Continued development
• Support

Points to the need for a sustainable community around the software… although the form this takes can vary a lot. Can mean both a community that works together to create software etc. but also can mean a community dependent on a single supplier (e.g. Microsoft)

Neil saying if you can identify the value of your s/w and who values it, then you can work out the market segment appropriate to the user base and the likely amount of resources available. Value for users becomes value for the software – the long tail allows software to be niche if you can tackle the issue of preserving software over time at reasonable cost (i.e. reduce the stocking costs).

So how do we create communities around software? Need to understand:

• Who the users are
• Why do they use it
• What do they value it
• What is the relationship between developers and users
• What do people want to do – not how can they use what we’ve got

Need to turn ‘users’ into collaborators and ultimately contributors – moving from a single team at a single organisation into sometime more diverse, and sustainable.

Need to remember that ‘trivial’ barriers are sometimes insurmountable – what is easy for one person is often frustrating for others. Perhaps especially between s/w developers (or those with access to development resource) and those without tech skills (or access to appropriate resource)

One of the difficulties is you have to give up control – the community may not want software to go in the same direction that you originally envisaged. I think this may be a key issue – if we look at successful Open Source projects there is often a guiding force (e.g. Linus Torvalds, Apache Foundation) which has some kind of ‘vision’ even though big community  – and not always consensus about where software should go (and hence forking of code etc.)

In summary – how to keep good software alive:

• Understand the value
• Identify the community
• Leverage technology
• Improve process
• Keep people engaged – celebrate success
• Encourage contribution
• Tell people about good software – if you like it, others are likely to