Archive for April, 2010

Open innovation builds success at LEGO

Published by Ross Gardler on April 28, 2010 in Business, Community and Development. 0 Comments

Six years ago, LEGO was on the brink of bankruptcy, as reported by PRESANS on the “Open Your Innovation” blog. LEGO had suffered in the 1990s at the hands of video games and computers, and had negelected its relationship with its users during difficult times. Today, under new CEO Jorgen Vig Knudstorp, it has turned its fortunes around and the familiar little coloured bricks are as popular as ever.

Knudstorp achieved this dramatic turn-around by establishing an innovative client relationship through the creation of a social network dedicated to children and LEGO bricks. This user community – accesssed through 40 ‘LEGO ambassadors’ in over 20 countries – provides valuable market information and is completely integrated in the design of new products.

Young adult interest has also been harnessed, through LEGO Mindstorms, which are programmable by computer. When advanced users began hacking the system in ways LEGO hadn’t foreseen, LEGO decided to utilise their ‘collaboration’ instead of fighting it. This enabled it to benefit from cloudsourcing and draw on the creativity and intelligence of a large number of users.

By opening the companies innovation processes to the outside world LEGO have recovered from its near-death experience. At the Transfer Summit we feature practical discussion, case studies and networking to enable you to realise the benefits of open developent within and beyond your own projet boundaries.

Using version control to manage Intellectual Property

Published by stevelee on April 23, 2010 in Development. 0 Comments

Intellectual Property (IP) management is one of the least glamorous activities required when running a software project. And yet it may just provide critical evidence for a quick resolution when a project is forced to defend itself against an IP dispute. A recent example of an attack on a open source project can be seen in the high profile JMRI.org defence against fraudulent claims of patent violations. Proper IP management not only provides peace of mind for the core project team, it also ensures contributors are not individually liable for costs. IP management is particularly important in healthy open source projects as they may received contributions of uncertain copyright status from a wide range of people of varying and possibly unknown background.

Fortunately, while IP management may seem daunting, not to mention complex, in actual fact a large chunk of the requirements are met almost for free as a side affect of using common development tools. When used wisely, version control systems provide the auditing required to keep track of IP, especially copyright. This is indeed fortunate when you consider that a single contribution may touch a very significant number of the files or other constituent components of a large mature project.

When contributions are accepted into the project code base there is the possibility that some of the code was in fact not usable for legal reasons. Such contamination may come from IP violations such as the process being covered by an enforceable software patent (in the USA), or the contributor being neither the copyright holder nor having been granted appropriate rights. Even if, as recommended, contributors are required to sign a Contributor Licence Agreement to assign ownership to the project itself, there is still a need to track individual contributions in case of dispute.

So a project needs to track who contributed each individual bit of code as it is accepted into the core code base. As a brief aside, the projects governance model will describe who can commit into the core and under what circumstances. The other requirement for IP management is the ability to make various queries about who made a change and when. Any decent version control worth it’s salt will provide the basic facilities which when combined with simple processes provide basic IP management.

Version control tools by their nature keep track of changes and allow queries to be performed. A project need only ensure that every change is clearly marked with the contributors identity, bearing in mind that the commiter may not be the same person as the contributor. This also implies that commits should be carefully managed so as not to mingle changes from different authors; but that is bad practice anyway for basic auditing purposes. A simple approach is to insist that all modifications include the email address of author. Some tools such as the distributed version control system git make it possible to get such owner stamps to appear automatically in the patches made and submitted as a contribution.

For auditing purposes it may be useful to generate a list of dates of change per contributor and merge that with a list of IP agreements. If any specific part of the code is disputed then the facility to see who made a change and when is useful (often call the ‘blame’ feature). If a particular change is in dispute it is easy to find out the extent and which files are effected. Finally most version control systems allow notifications to be generated on commits which can be useful for notifying those responsible for checking IP.

Our article What is version control? Why is it important for due diligence provides more detail on using version control.

TransferSummit/UK: 24-25 June 2010

Published by Elizabeth Tatham on April 22, 2010 in Business, Community, Development, Event and Uncategorized. 0 Comments

Every two years, OSS Watch hosts an international conference, and registration has just opened for our 2010 event. At TransferSummit/UK, business executives, technologists and members of the academic and research communities will be able to meet and discuss requirements, challenges and opportunities in the use, development, licensing and future of open source technology. In an array of presentations – from quick-start sessions to real-world case studies to emerging showcases – international speakers from the worlds of commerce and academia will cover a host of topics. These will be divided into three tracks:

- Innovation: aimed at executive-level attendees, this track provides a top-level immersion into the world of open source. Topics include foundations, infrastructure, licensing, governance, community-building and more.
- Development: aimed at technologists, this track highlights the day-to-day practice of putting open source into action. Topics include version-control, IP tracking, user engagement and more.
- Collaboration: aimed at both technical and non-technical audiences, this track offers real-world case studies, proofs of concept, first-hand accounts and market trends, and analyses what’s up-and-coming in open source.

In addition, attendees will enjoy a keynote presentation, breakout sessions, a gala dinner at Keble College, ample networking opportunities and, an optional extra at no additional cost, a BarCamp on Saturday 26 June.

To be held in the historic city of Oxford, TransferSummit is being organised by OSS Watch, in partnership with key individuals and organisations from the open source community, including the Joint Information Systems Committee (JISC) and the University of Oxford.

Registration is now open (note we have 100 free tickets for people from the academic space; drop us a mail with your credentials to get the discount code).

Making your open source software releases more secure

Published by Sander van der Waal on April 21, 2010 in Community and Development. 0 Comments

When you’re writing code in an open source software project, you are generally using some version control system (you should!). Hosting websites like SourceForge and Google Code usually provide one free of charge, eg. a Subversion repository. All developers or other people interested in the source code use a client application to download the code and synchronize with the repository on the server. Users can download the source code using http or https.

Making your code available for external parties by using a version control system is a very good idea. But if you want to attract more kinds of users than just developers, you should also periodically create a release of your source code and make these separately available for download. Less or non-technical users will then find it easier to use your software and get involved in the project more easily if they don’t have to build the executables themselves.

However, if you release executables through your own (or a hosting) website, this is not entirely risk-free. If someone tempers with your binaries, eg. by adding malware to the code, your users may be downloading malicious code to their computers by using your software, and of course you would want to prevent that. Two ways of doing this are to hash the download and make the checksum available as a separate file, or by signing the release with a PGP signature.

Adding a checksum to your download
Several algorithms have been developed to generate a hash checksum for a file, eg. MD5 or the SHA family (SHA1, SHA128, SHA512). The purpose of creating this message digest is to assure that the file you downloaded is exactly the same file that was offered, so no one byte can be different. This does not only help against infringement from outsiders, but also helps you detecting technical errors in the transmission of the file. An easy, simple-to-use tool to generate hashes is the open source application GNU Privacy Guard. It supports MD5 as well as several SHA algorithms. In general you should use the algorithm with the longest hash key, as they are more secure. With brute force it is possible to break all hash keys, but a short key like from MD5 is much easier to crack than one like SHA512. The process is fairly simple. You create the checksum file for the generated download and upload them both to your website. The user interested in the download also downloads the checksum and uses a similar tool as GNU PG to check if the checksum is correct.

Signing your release with a PGP signature
Another way to protect your released binaries is to sign them with a PGP signature. You can use the same tool GNU Privacy Guard for that. When you start using it, you first need to generate a public/private key combination. You will have to publish the public key in a file, commonly this is one KEYS file for the whole project that contains the public keys of all relevant developers. Next, you can sign a release binary using your own key, which will result in a signature file, which is quite similar to a hash key file. Now anybody that can download the binary, your public key and the signature file, can check whether the signature matches with the public key and the binary. This will ensure that the file that has been downloaded is the same file that has been created by you, the release manager.PGP signatures can provide an extra level of protection by identifying that the public/private key combination that signed the binary indeed is linked to the individual. It works in a decentralised way (as opposed to the PKI method that needs a certifying authority). Once you have created your own keys you can exchange your public key with other users and thereby add them to your web of trust. You do that by signing each other’s keys, but you should really do this in person to make sure you know who you are dealing with, eg. at a conference.

Finally, if you’d like to know more the Apache page on signing is an excellent resource. For more technical details about signing Henk Penning’s page is very informative.

Then, as a really final note, I should add that these mechanisms of securing your releases are not error-free and don’t fully guarantee that people with malicious intentions can do harm, because they usually always can. However, the described mechanismsdo make your releases saver than not using any security and it’s therefore a good idea to use them.

More open source accessibility news from CSUN10

Published by stevelee on April 5, 2010 in Community, Development, Event and Software. 0 Comments

In my previous post on the CSUN10 conference I concentrated on the GNOME accessibility team hackfest and booth. An audio version of that post recorded while at CSUN has also ended up in the new Access Collective podcast from David Banes of AbilityNet. This time I want to describe the exciting activity of the Project:Possibility who encourage computer science students to work on open source accessibility projects through competitive events. I’m on the board of Project:Possibility and this year we worked with the GNOME accessibility community to offer the students a chance to work on established projects to the teams, gaining sort after skills. Accordingly this post is largely written with my Project:Possibility hat on.

However before that I like to mention news announced at CSUN that Adobe will be adding support for IAccessibile2 to Reader and Acrobat. IAccessible2 is an enhanced accessibility API for Windows that is an open standard maintained by the Linux Foundation, so the announcement by Adobe is a good affirmation of the standard’s position.

At the other end of the corporate-to-personal scale, BryenY who was with GNOME at CSUN and also used a number of signing interpreters, describes how these interpreters clearly explained all they had learnt about open source through performing their work.

As for the Project:Possibility student teams from USC and UCLA who won the SS12 accessibility coding competition? Well the CSUN organisers arranged for 2 events to showcase the programs they had created. The first was an informal ‘meet and greet’ requested by Dan Hubbell of Microsoft, who sponsor of CSUN. Dan wanted to meet us all and suggest the students also consider the Microsoft Imagine cup for future activity. We invited the GNOME accessibility team and others who we thought would be interested and the event was very successful. The students presented themselves very well indeed, stimulating interested discussion. Project:possibility gave a brief introduction to our work as well.

After the meeting, Willie Walker presented the students with Friends of GNOME t-shirts and the CSUN students stayed with Ben Konrath, Caribou maintainer, to work on further improving their winning code to make it suitable for submission into to the GNOME code base. This was key as the reason for offering GNOME projects to this years SS12 teams was to make sure the code they produced did not stay on the shelf, but rather lived on as something useful for users. Although we were concerned the students might find it daunting to work with an existing open source project, we were very pleased to find the students said this was actually a positive draw, as was the chance to have a mentor experienced with existing code. We are hoping that the USC team complete the work getting their code submitted, and indeed they expressed a great interest in seeing their code in a standard Linux distro like Ubuntu. If they do we’ve arranged that they will get a GNOME certificate from Stormy Peters that will bolster their resumes.

The students were also given an opportunity to present their work on the Saturday along with students from San Diego State University. I tried out both the mobile currency scanner running on a Nexus One phone and the new binary input mode for Caribou. There was quite some interest and again the students gave a very good impression.

CSUN University have stated they will definitely enter the SS12 next year and we hope to see their students in the finals. There is also much interest in the idea of having the SS12 finals as part of the CSUN conference next year. Other ideas include working with high schools and having many more SS12 competitions. So along with the clear interest we saw for GNOME’s accessibility solutions, I’m pleased to say Project:Possibility are also raising awareness of open source accessibility and the benefits it offers to users and developers alike.

Finally I’d like to thank OSS Watch for sponsoring my visit to CSUN10 and so enabling me to experience and contribute to the success of open accessibility this year. We also raised the profile of OSS Watch as a experts in open source development.

The growing popularity of open source assistive technology: Interview with Will Walker

Published by stevelee on April 1, 2010 in Community, Development and Discussion. 0 Comments

The day before I discussed the importance of open source screen readers with Joanie I interviewed Will Walker about open source accessibility and development of assistive technology. At the time of the interview Will was still module maintainer of the Orca screen reader, a role Joanie has since taken on after Will had to step down. Will also vacated the position of GNOME accessibility lead, a post that is still open. Will gave some of his insights gained through many years working in open accessibility software development and serving user needs.

We cover the recent growth of interest in open source assistive technology and its relevance to users (01:20), how GNOME accessibility features help developers (04:25), the ease of developing when open collaboration is possible between projects (06:05) and simple ways to encourage users to become, and stay, involved (08:15).

Listen to the audio below or download it in mp3 format.

[audio:http://fullmeasure.co.uk/Stuff/Will.mp3]
Running time: 13 min

Note: If you’re wondering why I checked that Will was not going to sing a song then this post by Eitan Isaacson will explain all.