Archive for December, 2009

Apache Wookie (Incubating) and the W3C Standards

Published by Ross Gardler on December 18, 2009 in Development and Community. 0 Comments

OSS Watch are working with Scott Wilson and his colleagues at the University of Bolton on the Apache Wookie (Incubating) project. Since I’ve been busy on other Wookie things today I’ve not had time to write a blog post, so I’m just going to steal one of Scotts (well, I say “steal” but it’s under creative commons on Scott’s blog so it’s not really stealing).

Apache Wookie passes W3C Widgets conformance

After a marathon code sprint [well done Scott - RG] Apache Wookie (Incubating) now passes all 166 W3C Widgets conformance tests, the third application to reach a 100% pass rate.

Two other applications - the Aplix Web Runtime engine and the BONDI reference implementation for Windows Mobile - have also been able to successfully pass all the conformance tests. Several others are also approaching a full pass rate, as can be seen on the W3C implementation report.

Not only is this good news for Wookie its also good news for W3C, as more successful implementation helps the progress of the specification. Also, open source implementations can also help other developers build interoperable applications by reusing code. I hope in future we’ll be able to make the widget parser in Wookie distributable as a standalone library as well as part of the Wookie widget engine, to help with this process.

Useful links:

Mailing lists vs. forums

Published by Sander van der Waal on December 15, 2009 in Development, Discussion and Strategy and Policy. 5 Comments

On Monday the 9th of December we organised two simultaneous workshops on open development. One track was about open innovation whereas the other focused on the theme of building an engaged community around open source software projects. I gave a presentation on the latter track about my first experiences with an open source project and explained about the community tools that are essential for open development: a good homepage, a version control system, an issue tracker and mailing lists.

One question at the end of my session was about the mailing lists. I had explained that it is very important to have a publicly accessible mailing list that anybody can subscribe to and that you should ensure that all communication about the project is on the mailing list. The question was about why you should use mailing lists for this and not forums.
Continue reading ‘Mailing lists vs. forums’

Open Source, Open Development, Open Innovation workshop

Published by Sam Jordison on December 11, 2009 in Event and Development. 0 Comments

A workshop run on December 7 2009.

Introductions

More and more researchers in the UK understand the concept of open innovation and more and more universities say that they support it. A large percentage of them even have a policy to adopt open source software.Even so, the number of open innovation projects running in UK institutions is still low. More clearly needs to be done - both to persuade people to adopt open innovation policies and to enable them to do so.

This workshop was designed to show how open innovation works in practice and how open innovation concepts can be applied to software development. In providing successful working examples of open innovation it also had the side benefit of making a good case for its application. (Although during the course of the day quite a few interesting problems and issues relating to open innovation were also teased out.)

4176669102_65af33ce57_o.jpgRoss GardlerRoss Gardler from OSS watch introduced the day with a brief overview of the work carried out by OSS Watch in running workshops, providing speakers and expertise and advice: “We don’t make decisions - we help others make informed decisions.”

What is open innovation?

Ross also helped define the terms of the day by quickly explaining the principles of open innovation and citing the JISC description of a system that: “involves opening up parts of the development lifecycles for research, teaching and knowledge exchange .. external to the institution… in order to bring new perspectives, resources and collaborative opportunities.”Once these terms were laid down (and after Ross had given the most famous example of open innovation at work - the internet) we moved on to the first talk by Tim Francis from Pera.

How and where does open innovation work?

Tim built on Ross’ concise definitions of open innovation by giving Henry Chesbrough’s famous statement from 2003 that: “Open innovation is the use of purposive inflows and outflows of knowledge to accelerate internal innovation, and expand the markets for external use of innovation, respectively…”He followed with examples of companies that have made use of open innovation practice. These included: InnovationXchange, Innocentive, and Spread Shirt. The common strand tying these examples together – aside from their adoption of open innovation – was their rapid growth and success.Yet, Tim said, there are also serious issues of trust, problems relating to overcoming cultural differences between companies and academia and problems relating to feedback mechanisms within organisations that have tried to adopt open innovation.He cited a report that Pera carried out for JISC earlier this year, which showed that currently “there’s a lot of dissatisfaction.”

Open innovation in the Apache Software Foundation

Fortunately, the next speaker, Bertrand Delacretaz a senior developer at Day Software www.day.com and a member of the Apache Software Foundation was able to declare himself pleased with the way open innovation has helped his work.

Bertrand Delacretaz

The Apache web server, he says, powers 60% of servers around the world “and it relies on open processes and open code and quite a bit of crowd-sourcing.”Bertrand says that a good bit of Apache’s success can be attributed to the quality of the feedback that everyone working on it gets when they have something to add to the programme.

He then gave a detailed description of the feedback processes that the Apache developers use, including mailing lists alerting people when code is committed to the programme’s central repository, events issue trackers, email discussions and automated tests.“It’s really useful,” he said. “It helps develop a shared vision. There’s no scattered information. All decisions are made through mailing list. They get real-time status updates. They can do real-time help requests. It also helps create self-service archives. And the beauty of open-source is that you can do this in collaboration with your users.”

Emerging themes

During the course of this talk (Bertrand has helpfully posted the slides for this on his blog) one of the major themes of the day also began to solidify – that open innovation is not about chaos and throwing away control of projects.

Apache is carefully managed and there are numerous procedures in place to ensure projects have momentum and integrity. So, for instance, new developments will generally have an incubation period during which their direction is determined by much smaller groups of people before they are opened out to the wider community – and there are many safety nets when it comes to inserting new code into programmes.Also emerging by this stage was the question of whether or not open innovation really encouraged new ideas, or whether innovation is actually more often down to a few individuals. Delegates had asked it in different ways of Tim, Bertrand and Ross. Bertrand now answered by saying that open innovation “allows ideas to blossom”. It provides those who have had them with the feedback they need to take them further – and practical help in doing so.

Open innovation in TexGen

Professor Andrew Long from the University of Nottingham gave another example of a successful open innovation project – TexGen.You can get good details about how TexGen works here, but Professor Long also provided some interesting history of its genesis, including the fact that he had to be persuaded to make it open source by some PHD students “of the sandals and Linux” persuasion.

The experience of open source at TexGen appears to have been largely positive. Many more people have downloaded it than would have done were it not freely available – and much more money has come into the project than would have done otherwise. Professor Long cited funding that came in from Unilever and Voith Paper Fabrics for further research, saying he was convinced they wouldn’t have contacted him were it not for the fact that TexGen was open source and the businesses could see what it involved  - and indeed find it more easily in the first place.Professor Long  - although happy to admit he’d like a swimming pool – noted here that money wasn’t the object. It was “a happy spin off of the process” that allowed him to employ more people and do further research. But this financial success does help illustrate one of the points Ross was keen to emphasise throughout the day – that “open innovation is not the opposite of commercialisation.”

Problems in implementing open innovation

After the presentations, delegates were presented with a self-assessment exercise (which you can find here) designed to test how open and sustainable their projects were. As these results show, few scored particularly highly. “Knowledge in our sector is a problem,” concluded Ross. There were also problems relating to legal issues and marketing.

4175886685_951f758f97_o.jpgDelegates fill in their surveys

Discussion and conclusions

Negative as all that was, delegates did at least all say that the exercise had been helpful and the questions had helped guide their thinking.

More praise for the day emerged during the concluding discussion session and there seemed to be a broad consensus that – as one delegate suggested: “there was a line throughout that shows that open innovation would improve research.”But serious questions were also raised about how to bring about the cultural change that will allow for more open innovation programmes, and how to allow for the recognition and career advancement that academics naturally desire as a result of their work.

The lack of good open source software suppliers was also highlighted. Again the counter-argument emerged that much science depends on individual inspiration rather than group collaboration.Ross actually agreed with this latter point and acknowledged that open innovation may not always be the best fit. “But in other areas it does work,” he said. “The big thing about changing culture is to do it and show that it works.”The workshop had certainly achieved this latter aim, judging from the feedback in the session, and my own conversations with delegates who told me they had been given “plenty to think about and play around with” , given “really interesting pointers” about ways to shape the management structure of open innovation projects “not to mention a bit of inspiration”  and “a lot of interesting approaches to the issue”

But it’s also clear that much more work needs to be done to maximise the potential of open innovation across academia and in software development.

Writing for the Web: a few tips

Published by Elizabeth Tatham on December 5, 2009 in Event and Discussion. 0 Comments

My worst nightmare at school was having to think of something for show and tell. I had the same feeling today, when I was asked to write a blog post as part of my new job as content editor for OSS Watch.

I have never written a blog before, and seldom read them, so I had a few questions for my colleagues. What shall I write about? Oh, anything really. Who am I writing for? Oh, anyone and everyone. Scary. All the more so because blogging is  personal and immediate - quite the opposite of the book publishing process I am used to, where the product is carefully crafted over several weeks or months and there’s a team to share the responsibility.

Luckily I went on a course yesterday, so at least I have something to write about. The course was called Writing for the Web, and I was keen to go on it because I wanted to know how the writing and editing processes for the Web differ from those in book publishing.

The course outline looked very promising: devising a strategy for your website; understanding how people read online; structuring your information; writing skills; managing your website; editing and proofreading; and creating reusable material. For me, it didn’t quite deliver on all fronts, but I did pick up some useful tips:

  • a website should not be seen as whole, and is non-linear, unlike most books
  • reading on screen is uncomfortable, so presentation is important (see http://webpagesthatsuck.com for examples of how not to do it)
  • consider the reader’s environment and accessibility issues
  • use storyboarding to plan the site, and to demonstrate layout of screens and navigation links
  • navigation reflects the relationship between information and also readers’ need to access it
  • people don’t read the text, they scan it, so make it scannable: use highlighted keywords, meaningful sub-headings and bulleted lists
  • keep headings short; the first two words are the most important
  • paragraphs should contain a maximum of two sentences
  • keep it short and simple (see http://www.plainenglish.co.uk/) and focus on the action
  • avoid ’speed bumps’: inconsistent use of terms, jargon, slang, non-descriptive headings, marketing hype

All in all, it was a useful day away from the office. I will now be able to look at our website in a new light, and think about how we could apply some of these principles to improve it, and the documents we write for it, for our readers. Pity we didn’t cover blogging.

Release management in open source projects

Published by Sander van der Waal on December 2, 2009 in Development and Community. 3 Comments

My experience with software projects so far has mainly been within the corporate sector. The projects I have been worked on involved a designer who wrote a functional design document in close collaboration with the customer, developers writing the software and software testers who did the QA and basically tested whether the software matched the design and worked without (major) bugs. The developers worked test-driven, whereas the software testers focuses on functional, end-user tests following the functional design.
Release management in these types of projects usually means that there are frequent releases, and the testers are testing release x while the developers are working on release x+1. When a critical bug is discovered, meaning one that makes it impossible for the testers to continue their work, a patch release x_01 is created in a branch. All non-critical bugs are scheduled for release x+1 to x+n based on priority, impact, and so on.

Now that I get more involved with open source projects, I experience in more detail some important differences as far as release management is concerned. When you are in a distributed open source software project, there are different ‘customers’ that each have their own set of use cases, quite possibly their own software developers implementing those, and few (if any) software testers. This makes performing QA and release management a challenge. How do you decide when a release can be created, what the scope will be and how will it be approved? Who will make sure a release is of a reasonable quality for all customers involved? Usually, with a distributed project comes distributed QA. Each customer will have to test for their own purposes, which makes it harder to coordinate a release. I would like to discuss two ways of organising the release process here.

Use release candidates

One possible approach is to use release candidates. For instance, if you plan to release version 1.2.0, you first create a release candidate 1.2.0-rc1. This release candidate is made publicly available on the website, announced on the mailing list and each developer is encouraged to test the release candidate in their own environment. In fact everyone involved is encouraged to test the release candidate in as many environments and with as many use cases as possible. A fixed period is designated for testing and critical bugs found are reported on the issue tracker and when there is consensus that this bug has to be fixed in the release a new release candidate is created in a seperate branch of the code, which will be labeled 1.2.0-rc2 and the process starts again. When there are no more critical bugs found within the test period, the release itself is created. This is exactly the same release as the last release candidate, but with the postfix of -rcx removed. Alternatively, the postfix -rc can be replaced with -ga, which means ‘general availability’.

Release without release candidates

In smaller projects where there aren’t many different user groups or developers you may consider not to use the overhead of the release candidates, but just go ahead and create the release. In our example you would rightaway create and publish release 1.2.0. But also in this case it makes sense to incorporate a fixed period of testing the release, to make sure the release is of reasonable quality. You don’t just want to dump the files out there, but would like to be sure that all the users with their different use cases have a release that works for them. A fixed testing period can help you in that process. If a critical bug is found that needs to be patched, you will have to publish a patch release, in our example that could be 1.2.0_01.
Whatever process you choose, be sure to always tag the release properly in your version control system. That way you can always create patches for the release, while continuing development on the main branch.

Release management revision

Whatever release management process you choose, the dynamic nature of many projects makes it valuable to adjust the process to your needs and for instance choose a mix of the two discussed methods. Your project may not require release candidates in general, but perhaps it makes sense to use release candidates for large releases. In any case, it is generally a good idea to revise your release process once in a while. Like methodologies such as Scrum teach us, evaluating the process is a valuable thing and this is certainly the case with release management in open source projects. Just make sure you have a good process in place for deciding on these issues and follow these processes carefully.