Archive for September, 2009

Learning real-world software skills through Open Development

Published by stevelee on September 21, 2009 in Development and Community. 1 Comment

In our upcoming Workshop that introduces developers in the practicalities of engaging with an open source project, guest speaker, Mark Johnson, will provide a real world example from his recent experience of contributing to the Moodle project. Real examples are a powerful learning tool and just as I had decided that we need to find more, an interesting example appears in my inbox from Dave Humphrey. Dave leads the Mozilla development courses at Seneca College Centre for Development of Open Technology. This course allows lucky students to get to grips with a real, large and ‘hairy’ code-base and engage with an active community in the form of the popular open source ‘product’ Mozzila Firefox and its sibling Thunderbird.

In this case the students engage in order to learn how to work with open source code through the open development processes that are encapsulated by the Mozilla governance model. This exposes them to many of experiences and critical skills that employers are crying out for but that can be extremely hard to teach in a computer science course.

David actually describes one of his own experiences of open development in his blog post, and I leave you to read the entire post which is quite complete in itself.  While he covers only the early stages of the entire process of adding a feature, Dave does mention the later process such as code review. Dave’s problem is how to get code that works in one context to also work with an older version of the Mac operating system OS X, as required by the current release of Thunderbird. The following  snippet encapsulates the point I wish to highlight here.

Now I was convinced I needed to do this for real.  But how to deal with the differences between OS X 10.4 and 10.5+?

I wasn’t sure, so I did what you do in open source: I a) looked at the other Mozilla source code for clues; b) asked some people who might know.  Looking through the code I saw lots of compile-time checks, but nothing at runtime.  I needed to know when the app started-up what version I was on, and therefore which API to use.  Next I tried asking on irc, in the #macdev channel.  It was almost midnight, but luckily three people were around, and they each had a different idea for me: 1) I could consider using nsToolkit::OnLeopardOrLater(); 2) I could try doing what was done for the wifi scanning code (e.g., try, fail, fall back); 3) try to add this version check to another bug that was doing similar things.  I read through all the options, and went to bed unsure of the best solution.

The next day I decided to ask two more people.  One of them was the person who would eventually review my code, so his opinion mattered to me.  The other was a friend who works for Mozilla and knows a lot about dependencies between various parts of the code.  I really wanted to use nsToolkit::OnLeopardOrLater(), but it isn’t exported (e.g., it’s an internal API, and the .h file is not accessible to my class).  They both suggested I just copy the code into my file, and later, when we move to 10.5+ support, remove it.

I made the change, and now the code supports both 10.4 with the existing drawing code, and 10.5+ with the new drawing API.  I’m quite pleased with it, and hope that it gets accepted by my reviewer.  Regardless of  what happens, I learned a lot through this process.  I learned how to mix C++ and Objective-C code, version differences between OS X APIs, build system tricks, how we do dynamic version checks in other parts of the code, etc.  I was also reminded how much faster you can work when you work in a community setting vs. on your own.  Through blogs, public source code, and irc I was able to get this done with only a couple hours of learning and work.  It was time well spent, both for Thunderbird and for me.

I will make one point. Dave also learned  something of the kind of real world messiness and compromises that often have to be made when dealing with existing code and many complex requirements. Messiness such as complex build systems, a mixture of languages, incomplete support for platforms . In the relatively isolated academic world of the classroom you can often get by without having to consider such constraints and dubious architectural decisions such as ‘just copy the code into my file, and later, when we move to 10.5+ support, remove it’. The complexities of the real world can only be learnt by engaging with real developers on a real project. Open source projects provide an ideal place for students to learn important skills whilst contributing their energy.

Software innovation in academic software outputs

Published by Ross Gardler on September 3, 2009 in Event, Development, Strategy and Policy and Community. 2 Comments

At OSS Watch we spend a great deal of time talking about project governance. We argue that a lack of clear governance results in potential contributors being discouraged, either because there are no visible rewards for the extra effort involved or because they are worried that contributions will not be well managed. New projects often delay specifying a governance model and opening up because they don’t want to lose control of the project. However, this misses the whole point, a governance model does the exact opposite, it ensures you maintain control for as long as you want it. Furthermore, opening up is what drives innovation. This is likely to be the topic of my lightning talk at the JISC Rapid Innovation in Development event.

The goal of the #JISCRI projects is not  to have perfect software solutions, but to develop expertise in a range of potential solutions. By sharing this expertise across the whole community we not only increase the skills base of all, but we also bring ideas together - it is this converging of ideas that results in innovation, or, as Marten Mikos puts it:

innovation happens … when you encounter other people and also when you step over some boundary and you combine ideas that haven’t been combined before.

By adopting an open source licencing model and an open development governance model we allow anyone with an idea to bring that idea to the table, the governance model defines the mechanism for evaluation and subsequent acceptance or rejection of the idea.

However, at this point we hit another problem. People are often adverse to contributing their ideas because they also desire to control the latest and greatest innovations. A good governance model will reward the best ideas with a stake in the overall project. That is, it recognises that if we want to benefit from other peoples ideas we need to ensure they can benefit from our own. At this point please allow me to misquote Kahlil Gibran:

 If you love somebody a project, let them go, for if they return, they were always yours. And if they don’t, they never were.

If you create and manage a truly innovative project then the rewards will always come back to you. By allowing people to experiment with your project you encourage those people to dream up new innovations and to invest new resources into implementing those innovations. These resources and the expertise they bring is something that your project would never have if you failed to let it go in the first place. The trick is to make it more beneficial for the third party to work with you rather than to work independently, for this you need a good governance model.

This kind of collaboration happens a great deal in the commercial sector, but it is much rarer in the academic sector (although it does happen). The reason for this lack of openness is a cultural mismatch with two distinct causes. The first is that scientists are encouraged by the peer review system of publication to keep things close to their chests until the point of publication. The second is that universities are geared up to exploit innovations through patent licencing, which is not compatible with the idea of openness during the act of software innovation (this post is getting to be quite long, so I’ll save the exploitation issue for another post).

The fact that the peer review system prevents the kind of peer recognition demanded in open source projects is ironic since that system was devised to encourage openness. Micheal Nielson explains it well:

The value of cultural openness was understood centuries ago by many of the founders of modern science; indeed, the journal system is perhaps the most open system for the transmission of knowledge that could be built with 17th-century media. The adoption of the journal system was achieved by subsidizing scientists who published their discoveries in journals. This same subsidy now inhibits the adoption of more effective technologies, because it continues to incentivize scientists to share their work in conventional journals and not in more modern media.

My hope is that initiatives such as the JISC Rapid Innovation projects will help increase openness in the academic software development sector, but my concern is that very few of these projects understand the importance of being open from day one. I’ll be challenging people to prove me wrong in my lightning talk at the #JISCRI event and OSS Watch will be exploring the need for openness in our Engaging Developers workshop in October.