Archive for the 'Event' Category

Dev8D - where collaboration happens and skills are learnt

One of the most satisfying aspects of working for OSS Watch has been observing the outcomes from introducing people and then encouraging them to collaborate on new ideas. Outcomes such as personal development and new or improved projects. The recent Dev8D event was a real highpoint in several strands of OSS Watch activity and I was inspired to have been able to observe what happened and be part of the action. Dev8D is about developers getting together and seeding new project ideas, something that is an important aspect of open development, and so is important to OSS Watch. The Dev8D team, led by Mahendra Mahey, along with everyone who participated over the 4 days made Dev8D a fantastic event. Much developer happiness was expressed both during and after the activities, not to mention the many new project ideas that were hatched.

Several coding challenges where made and our very own Sander won 2 of them with MuCoMaCo an interesting Google map mash-up of MLA library data. OSS Watch have provided continuing support services to the Apache Wookie (Incubating) project from the University of Bolton. Recently Sander recently organised a Wookie Training day at OSS Watch. This was led by Scott Wilson, Wookie project lead, and Ross, OSS Watch manager. Scott was with us at Dev8D, so it was no surprise that Sander’s winning entry was a Wookie served W3C widget. This enables it to be readily deployed in a range of contexts with little effort.

The other winning entry that OSS Watch had close connections with was Wookie BaLTI. BaLTI is a sample Moodle course by Mark Johnson and Dan Hagon and features the newly developed Twirlymol and CollabMCE widgets. These 2 widgets use the widget loading and collaboration facilities of Wookie to provide a shared 3D interactive view of a molecule model and shared WYSIWYG editing. Several threads came together to make this happen. Those familiar with OSS Watch and open development will not be surprised at how open collaboration has made this possible.

Since we spotted Mark’s announcement of his first small contribution to Moodle and subsequently invited him to present it at an OSS Watch workshop, he has gone from strength to strength. At the Dev8D awards dinner Mark deservedly one ‘Best newcomer’. An award that provided him with a small Lego car kit, which we ‘knocked up’ during the meal, and a rather handmade certificate. The point is that Mark’s enthusiasm for learning about and contributing to open development has been noticed and is sending ripples through the HE and FE communities. Mark attended the previously mentioned OSS Watch Wookie training day, which stood him in good stead for working on the challenge with Dan. Since the Dev8D fun, Mark has pledged on the Wookie lists to reimplement his editing widget without the current LGPL licensed code dependency and to contribute it to the project. Further evidence of Mark’s personal development and it’s far reaching affects comes from his recent blog post. He also supplied us with this comment.

My manager appreciates the opportunities that open development provide to us as a department and an institution, both internally and externally. By letting me go to events like Dev8D even though the things I did there don’t relate directly to my current job, she gave me the opportunity to develop new skills which will allow me to provide new facilities to the staff and students in our institution. We’ve just started an ILT working group with our teaching staff, so hopefully I’ll be able to apply some of my new skills and knowledge to the ideas that come from that.

Mark’s collaborator, Dan, was the first person I met at Dev8D, and as with Mark you can’t help but be affected by his friendly enthusiasm. When I discovered that he had created an interesting Google Wave widget I steered him towards Scott and Mark and watched the magic happen. Scott explain how trivial it was to port the widget to Wookie, and once they’d decided on the LTI challenge Scott added BasicLTI interfaces to Wookie in order to support the challenge work. These are now part of the Wookie project code. More great collaboration followed and someone gave them an Amazon cloud server to install Moodle on. I observed them working together, discussing ideas, fixing bugs and working on their ‘judgement’ presentation. I tried to muscle in on the action with another widget idea but got rather distracted and bogged down in practicalities. Still I do have some new ideas to add to Wookie at some point.

I also attended their pitch to the judges as moral support and I’m glad I did. Chuck Severance of IMS and Sakia and Steve Vickers where in the judging team. A soon as the pitch was over, Chuck and Steve rushed off to add the widget to Sakai, Blackboard and WebCT. Chuck made the point that by using Wookie and LTI it is now possible to have something running in all these platforms, and in a matter of minutes. He then distributed screen shots around various lists.

Dev8D saw many other collaborative ventures seeded or strengthened. New skills were learnt by motivated developers and new contacts made. For example I enjoyed watching Chuck and Tobias Schiebeck work on a tricky Sakai bug. Finally I’d like to mention GNOME who were running an overlapping event in London. After a bit of prodding for collaboration, Willie Walker and Brian Cameron came over and presented on accessibility and GNOME work. Both were very interested in the accessibility possibilities of “Mr gadget” Ben O’Sheen’s demonstration of software to talk to wiimotes. A representative from Dev8D also went over the to GNOME usability hackfest and I expect we will see fruitful cross pollination developing from this mutual interest. Not least is the opportunity for HE/FE developers to learn from a large, established and successful open source project.

Building W3C widgets on the Wookie training day

Last week OSS Watch organised its first training day in Oxford. We got together with about 15 people to gain hands-on experience with Apache Wookie (Incubating). Wookie provides an implementation of the W3C widget specifications, so a lot of emphasise was put on building these kinds of widgets. We succeeded quite well in getting to know the spec and how to build widgets and ended the day with a nice collection of newly built widgets and even a submitted patch to the Wookie source code.

Scott Wilson, the Wookie guru from Bolton University, where it all started, started the day off with a presentation (pdf) of what widgets and Wookie are all about. Widgets are basically small mini applications that are designed to work in a small view area. Many platforms have created their own format for it, but the W3C is working on a set of specifications for it with a consortium of partners from both traditional computing and mobile platforms, which will lead to a true cross-platform standard which will hopefully lead to widespread adoption. A minimal W3C widget consists of nothing more than a config file and an HTML file, zipped up as an archive with file extension .wgt. The config file contains basic configuration such as the name, description and preferred dimensions of the widgets. The widget can furthermore include as much HTML, CSS, images and JavaScript files as one would like.

Apache Wookie (Incubating) is an application that provides a W3C-compliant widget server. You can use Wookie to deploy widgets and you can serve W3C widgets from the Wookie server in third party applications. Plugins have already been written for Moodle, LAMS, Sakai and Google Wave. Wookie also has a REST API that can be used to get, or create widgets.

After Scott’s intro it was time to get dirty. Ross handed out CDs containing the latest sourcecode of Wookie (which can be downloaded by anybody from Subversion) and prerequisites like a JDK and Apache Ant. His presentation (pdf) was about ‘how to build your first widget’. I was surprised to see that there were 10 people with Mac-books in the room, amongst 4 Windows machines and one Linux netbook. Apple surely knows how to impress the developer these days! After some initial troubles with environment settings etc. most people got up-and-running fairly quickly and were ready to build their first widget. Wookie provides handy Ant tasks for building and deploying widgets, which means that generating a hello-world skeleton widget is as easy as typing ant seed-widget and answering some questions about the name, description and dimensions of your widget. After you have started up the Wookie server using ant run you can deploy the widget using ant deploy-widget. That was it, quite easily. I must say, having moved away from Ant and using Maven2 for the last few years, it’s nice to be remembered of the powerful features Ant has to offer. Especially since Wookie uses Ant in combination with Apache Ivy, the dependency management alternative for Maven2. (To be precise, you can also use Ivy with Maven2 repositories). Ross also demonstrated how you can make use of OpenStreetMap JavaScript APIs to embed cool navigational features in your widget quite easily. You can check out his presentation (pdf) or directly check out the source code of the tutorial including the example JavaScript.

In his second presentation (pdf) Scott focussed on some design principles behind the widget specification and gave a walk-through of how you can design a more advanced widget by making use of features of the W3C widget object API and integrate with the Google Wave Gadgets API. No Wave server is needed to get this working, as Wookie can handle everything for you. Scott demonstrated a Task widget with collaboration features, that can be used by different users concurrently using State and Participants.

After the break it was high time for everybody to create their own widget and some interesting ideas had come up. One of us decided it would be much cooler to hack directly in the server code instead of building widgets and he submitted a patch to Wookie to allow hot deployment of a widget to ease the development/deployment cycle. That’s very cool, thanks Matthew!

The rest of us built some widgets for a wide variety of purposes. One of the nice things about the widgets was that we could easily merge them all together on one Wookie instance and show all widgets there. These were some of the widgets that resulted from this 1.5 hour hack-fest:

  • Video player embedded in a widget with fallback to other formats depending on the user agent
  • Display a list of links using output from one of the Yahoo pipes
  • Display the last.fm playlist of a user and show what that user is currently listening to
  • Show a canvas drawing where multiple people can collaborate by working on the same drawing using HTML5
  • Cool kids’ game where the user can name his pet dinosaur
  • Currency converter that (eventually) would use an external currency conversion provider

It was fun to see how easily you can create functional widgets. If you make use of external JavaScript APIs or data feeds it is also quite simple to create a useful (or not so useful…) widget. This was a nice conclusion of the day and seeing all the widgets we had created we thought we had deserved our beer and headed off to the pub. Thanks to Scott and Ross for making this a successful Wookie training day!

Building an Engaged Community

On 7 December 2009 OSS Watch hosted a mini conference in Oxford, at the University Club. There were two workshops running concurrently, one on Open Source, Open Development and Open Innovation, which we wrote about last month, and the other on Building an Engaged Community, which is the subject of this article. During the workshops we ran a live blog for remote attendees; you can see a transcript here. Amir Nettler of OSS Watch covered the morning sessions and I picked up the reins for the afternoon.

The workshop was introduced by Steve Lee, who gave a high-level overview of the topic, focussing on the open development model and what a strong community looks like, as distinct from the open source code that they may be working on. The need for a wide and diverse community of contributors was stressed: not just programmers but contributors with all skills are important, including artwork, marketing, testing, documentation, etc. A good community should be able to sustain itself and cope with people leaving and new people joining. The key to this has to be transparency: all the history and previous decisions should be open for new contributors to review, which will prevent settled issues from being re-raised by people who missed the original discussion.

The licensing and legal considerations of an open project are very important for the community. Contributors need to be sure they have the legal right to give their contributions to the project and if necessary modify the terms of non-disclosure agreements or contracts of employment that could otherwise cause problems down the line. Some projects have contributor license agreements to protect the provenance of contributions; this is something a new project should seriously consider. To provide more information on this OSS Watch has produced a briefing paper on contributor licence agreements.

There is a wide range of free and open source tools for managing a distributed community-based open development project. Most community projects have some kind of shared communication system such as a mailing list or forum; critical to this is the history or mailing list archive being publicly available to new contributors. If the code is open but the communications are closed, the community will struggle to grow. A version control system should be used right from the start of a project to track who contributed which bits of code. A structured system distinct from the project communication system is used for tracking bugs.

Sebastian Brännström of Symbian treated us to a beautifully designed set of slides for his presentation, on how Symbian is moving from a very closed platform to an open development model. Sebastian has written open source software to run on Symbian and now works in delivery management for the Symbian foundation. In terms of governance, the foundation is set up as an independent not-for-profit organisation, which facilitates development but doesn’t actually do development as part of its activities. The foundation started with 12 member organisations, which has now risen to about 180, and has 90 employees. In order to give structure to the governance of such a large project it created four councils to control different aspects of the platform: features and roadmap; user interface; architecture; release management. An interesting aspect was the deliberate selection of structures that make it easy for anyone to influence the direction of the project, not just the larger members such as handset manufacturers.

Sander van der Waal told us about his work with the Apache Felix project. Apache Felix is an implementation of a standard framework called OSGi which defines a modular system for Java applications which amongst other things allows parts of a system to be updated whilst it is running, a powerful feature for highly reliable applications. When Sander got involved in Apache Felix it was in the Apache Incubator, which is a part of the Apache project where young projects are guided through the community building process. His project team started by reading and following the mailing lists for some time before joining in. They found it important to keep all communication on the list. This included communication between colleagues, even where a direct communication option was available, as it was better to keep it to the list so that the information could be shared and archived. Sander went on to explain how the integration of an issue tracker and revision control system is used in conjunction with a mailing list, allowing visibility of who contributed each line of code and which issue each change addresses.

Mark Johnson of Taunton’s College gave a talk on getting started in joining a community from a development perspective. Mark started contributing bug fixes to the Moodle virtual learning environment and took us on an introspective tour of the sequence of events as he progressed from using and administering a Moodle installation to being a part of the community that produces it. Collaboration is an important aspect of open dev, and Mark thinks, if done properly, a collaborative development process produces the best results. As well as raising his personal profile, Mark has benefited from the quality checking and motivation that working with others provides. Mark went on to warn of the dangers of over-collaboration: soliciting opinions from too many people leads to confusion, and bad design. He suggested limiting how widely you consult in discussion phase, produce a prototype/proposal and then have that critiqued; the existence of a tangible contribution limits how widely people’s suggestions can range. You don’t need to please everyone all the time, the objective is writing great software and some healthy disagreement and debate is a part of this.

Steve Lee then kicked off a session on evaluating the openness and sustainability of open source projects using an online form developed by OSS Watch.

This was an audience participation activity, which gave me a bit of a break from the live blogging and a chance to take a quick photo of the audience as they gathered in clusters around an assortment of laptops. I counted three Macbooks, four running some kind of Linux, and three on Windows. Everything points to a more diverse computing landscape over the next few years, with different devices talking to each other using open standard protocols and formats.

I found the results of the activity very interesting in that the audience had no problems choosing projects they were working on or in their own specialist area of interest. Nobody attempted to evaluate the projects with the broadest appeal, such as Firefox and OpenOffice.org. I think this, and the range of resulting scores, points to the evaluation having good practical value for the OSS Watch sector.

The event closed with a panel session in each room, I will pick out a few topics that were covered; there is more in the transcript. The first questions were “Should a project accept all contributions” and “does it matter if a contribution is ignored?” All the panel members stressed the importance of managing contributions and responding to contributors; if a contribution is not used it is critical to provide feedback so that the next contribution meets the required standards for acceptance. Sebastian Brännström said that taking contributions seriously was critical to keeping users and the community happy.

The discussion moved on to the issues faced by smaller projects with a team of core contributors. In order to increase the number of active contributors projects should focus first on increasing the number of non-contributing users and lower the barriers to new contributors, helping users progress to being contributors.

The final question was “What pub are we going to?” the answer to which turned out to be the “Far From the Madding Crowd” where discussions continued into the evening.

Open Source, Open Development, Open Innovation workshop

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

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.