Retrofitting the framework?

I'm currently working on a number of finished JISC projects and trying to turn them into SUMs. Part of this means that I need to produce some guidance documentation for other JISC projects to make this a lot easier in the future.

This is going to be chatty, and I'll be reformatting later on to make it more acceptable.

I've got 20 or so projects that I am looking at, and I think some of them are SUMs, some are expressions, and a number are presenting ideas for new genres. I've got access to project websites and documentation, if I can find it.

So first note for a JISC project - DO NOT BURY YOUR DOCUMENTATION IN A PROJECT BLOG!!!!
By all means, link to the documentation in the blog, but please make sure that you've got another link somewhere else that's reasonably prominent (say, in the documents section).

What have I been looking for?

First thing I've looked at is the projects homepage, if I can find it. In some cases projects that have finished no longer have homepages, so maybe an issue for JISC or the institutions here.
I'm looking at the homepage to give me an idea of why the project has been done. Usually projects are good at this- "there was this problem and we wanted to tackle it". I can then use this pretty much directly in the rationale and/or description of the eFramework Component.

Also embedded within the project's homepage is a bit of information on how they attacked the problem. Usually in here I can get an idea if they've developed a new Service, or a SUM made up of a number of seperate services. No real trick to how to do this, but if a project talks about "multiple services" or "we linked this and this" it's possibly a SUM.
At this stage, it's all been very general, and is more of a feeling of what I am looking at, rather than really knowing.

Next step is delve into the project website and try to find the technical documentation. Ideally, I want the analysis document, or failing that an architecture or technical design. SUMs are all about how to link business analysis back to services, and then how to use a number of services to achieve an end result.
Kerry Blinco has said that there are different SUMs for different purposes - and we have a notion of Genre SUMs vs Expression SUMs. A Genre SUM tries to explain how the various genres link up; the expression SUM does it in a much more "go and implement" kind of way. I've tended so far to look at the projects work in terms of ideas where I can.

Next thing to do is consider the functionality of what the project has tried to do. This is easy with an analysis document, and a lot harder with a design. But the design does make identifying the individual messages a bit easier; so ideally I need both documents.

Now, working on these things from within a project has to be a lot easier than trying to do it externally. This is particularly true when a project has developed a webservice, and the API isn't documented in a meaningful way...

Is good development practice the strength of open source?

Yesterday I was fortunate enough to see Ross Gardler of OSSWatch (http://www.oss-watch.ac.uk) doing a presentation on Open Source, and how it applies to JISC projects.

OSS-Watch, in Ross's words, is not an avocacy group for Open Source, rather it seeks to educate and inform. Ross himself has very strong open source credentials. He's a member of the Apache Software Foundation; it was refreshing to hear some good, strong, reasoned arguments about open source, rather than the table thumping that I've encountered in the past.

I'm a bit awkward when it comes to Open Source software. I use Firefox and Thunderbird, I've got Mysql, tomcat, apache and all sorts of other bits running on the office server. We use mediawiki here too, for all things from marketing to recording useful bits of information discovered from the work that we do. I've used open source libraries as a software developer in the past too - anyone that's ever heard me rave about how wonderful Hibernate is will be aware of that. I'm not as hardcore as some of my other colleagues though - who tend to use Linux as a a desktop OS.

No, I'm awkward because I don't think the degree of "open-sourceness", is an indicator of anything really, other than the degree of "open-sourceness". I use firefox, not because it is open source, but because it is (in my opinion), the best tool for the job. For a long time I used Internet Explorer, but version 7 and myself just didn't agree, so I looked for something else. There's a lot of great open source stuff out there; there's some great proprietary stuff too - but there's also a lot of software of both varieties that isn't quite so great.

Now that we've got that aside, I'll look at the part of Ross's presentation that I thought was really good. I'll put my awkward stance on it as well though.

Ross presented on some open source tools that make development easier. Things like ant, the build tool; and junit, a unit testing rig. He also described source repositories, issue trackers, ticketing systems, installers. He described also how important it is to build a community around the software - to facilitate user engagement and feedback to and from developers.
Now, I am not arguing with any of that, it's all good.

My question though, is how much the degree of "open-sourceness" affects the above? I think the tools that Ross mentions are ones that all software development projects should use, be they proprietary projects or open source ones. Further, the tools are all fairly common - so there are open source versions like the ones that Ross (and I) use, but there are also ones that tend to come with the server versions of the various development products.
Every project, be it closed or open source, should use a source repository. Every project should do the nightly checkout and build. Every project should have an issue tracker. I don't think Ross would disagree with me either.

We also mentioned docmentation. Again, documentation is one of those things that both open source and proprietary types do with various degrees of success. Mysql has great documentation and its freely available, but some other projects have documentation thats only available if you pay for it. I'm not necessarily against that, as I realise that developers and documenters have to eat - but sometimes it can leave a sour taste in the mouth. Of course, with proprietary software I usually get the documentation as part of the licence; but no guarantee of quality. Great documentation comes from professional documenters - take a look at TechScribe (http://www.techscribe.co.uk)

Documentation, Testing, and Release Engineering are probably the areas that get skimped on when a software house or project has it's back up against the wall. So it's refreshing to see Ross bringing these out into the open on day one.

Ross also talked about building a community around the project. I think this is a thorny one. I've worked on projects that have stalled the moment the funding ran out - be they commissioned works from a software house, or funded projects from organisations such as JISC. The EU demands that a "sustainability plan" is in place.

I don't think it's that simple though. Communities tend to build because people have a common interest. They grow when the common interest appeals to outsiders. Genuine sustainability comes from having a solid business case. Why? Software Development costs money - pure and simple. For a software house, that money comes from sales; for funded project development, the payment is from taxation ultimately. Herein lies the problem - funding research is different from funding product development (and rightly too!). Funding Research is all about recognising that perhaps there isn't going to be anything sustainable at the end. Product Development is all about having sustainability in mind from day one.

I'm not convinced that building a community is easy, unless the problem being solved is one that is faced by a lot of other people - and that to me that is the differentiator. Don't get me wrong, I agree with Ross that having the community in place is an asset; but to get the sort of altruistic level of involvement that the model open source projects achieve; that is a tall order - if it's even possible. I reckon communituies form and grow organically rather than be something planned.

Of course, communities exist for Proprietary Products too - because communities tend to form wherever there is something successful.

Coming back to my original question, without a doubt, Ross hit the nail right on the head, and I know of more than one commercial company that could learn from the development practices that he was talking about. All in all great stuff - a very professional view on how to develop software - and perhaps something that the table bangers should focus on rather than... banging tables.

Productisation

I was invited to speak at a JISC meeting on Monday to promote the eFramework programme. The audience consisted primarily of academics and software developers that work in academic institutions. I was one of a number of speakers, and topics ranged from the Open Source Maturity Model all the way through to legal matters.

I was fascinated about the legal side - so fascinated in fact that I thought about trying to find a lawyer to co-author a white paper. The speaker on legal issues outlined where a lot of academics go wrong on the legal side; and such problems often manifested when the institution had noticed that the researchers had developed some software that was marketable. This got me thinking. Naturally there are legal issues to take into account when looking to sell a product drawn from research work, but don't forget the other issues...

Primarily, research code is not product code. Research code is written for a research project.
Product code is that which goes into a product which is going to be sold (probably) to customers.

The first difference is that the product code has to persist once the developers have moved on. Therefore the code has to be written so that any new developer can pick it up and run with it.
Secondly, code in a product is used a lot more than code in a project. There are all of the people that have bought that product are using the code. If errors occur, the people working in support need to have as much information as possible on the errors and their causes. There are some other differences, but I won't dwell on them now.

These differences arise due to the environments where the code is crafted. In a commercial environment, if you make life hard for support, then they refer more queries to you. So you make life easier. Likewise if you are given some code which is poorly commented (or not commented at all), then it takes you a lot longer to fix the bug or pick up the library. In the research world, the important thing is getting the problem solved. So you are less worried about what will happen next year when you've moved on.

Now all of this happens before we look at usability testing, integration testing, stress testing, documenting, installation scripting and so forth.
All of this is what a colleague once called "productisation" - taking prototype or research code and building a product from it.

Just as senior academics need to be aware of the legal issues that surround the exploitation of their project, so do those developing it need to be aware of what will happen if the software is going to be moved out of the department and more widely used. Institutions, of course, need to realise that developing a software product is expensive- and the developers need support.

One final word, and this applies to anyone writing software. Keep it easy. I know you are a better programmer than I am. You don't need to prove it by writing code that I can't understand. We've both got deadlines.