Archive for October, 2009

Meetup on the Apache Wookie project

The Wookie project is currently one of the Apache Incubator projects, but it has originated from a research project at the University of Bolton. Recently, OSS Watch organized a workshop on how to engage developers with open source projects. Scott Wilson gave a presentation there about how Wookie has evolved into an Apache Incubator project and how this fits in their strategy towards becoming a sustainable software project. Sustainability in open source projects is an important topic for OSS Watch and engaging developers in your project is an important part of that. At that same workshop Mark Johnson showed in a very entertaining presentation that it can be very rewarding and fun for a developer to get involved in the development of an open source project. He presented his personal story about how he contributed code back to the Moodle project which helped both his project and Moodle.

There was a meetup on Wookie recently that is covered in detail here. At this meetup Ross Gardler explained the incubating process at Apache and reasons why Apache is a logical place for the Wookie project. Furthermore, Scott Wilson explained the Wookie project in more detail. You can find the sheets of his presentation here. Lastly, Wilbert Kraan held a session on the combination of Google Wave and Wookie.

Get the most from open source accessibility with help from OSS Watch

Open source accessibility and Assistive Technology projects offer very real benefits to FE colleges and the individual students they support. The zero licence cost of open source plus the freedom to copy and redistribute are well known and provide great flexibility in how programs are deployed. More significant benefits derive from those projects that practice open development and thereby allow anyone to contribute or collaborate. Users can obtain community support from other users and developers, they can formally report issues and collaborate on new features, perhaps specifically required for individuals. Further, if the college creates it’s own in-house adaptations these can be passed over to the project becoming available in the next version for all to benefit from.JISC OSS Watch advise FE colleges and HE on engaging with open source projects and those that practice open development. We do not advise on specific programs or projects, rather we help you understand and evaluate open source so that you can confidently select programs and guide you in ways to most effectively engage with existing projects. We are expanding our understandingly of how and why open source is important in the accessibility domain. For example we have a case study on AccessApps from the RSC Scotland North & East and another on the ATutor accessible VLE. These can be found on our website along with articles that explain how to get the most out of open source software and how to develop software in an open community.If you use any open source tools that you think would make good case studies then please let us know. We are also interested in hearing of FE or HE projects that we can advise.Website: http://www.oss-watch.ac.ukRSS feeds: http://www.oss-watch.ac.uk/rss/Twitter: http://twitter.com/osswatch

Encouraging community contribution with a small example

I previously blogged how Mark Johnson provided an excellent example of contributing local changes or bug fixes to an open source project. I was impressed that while the contribution was very small (1 line) it managed to encapsulate the process and so acted as a good example for illustrating how to engage. Accordingly I drew out the process that Mark followed from his post.

Whilst planning our recent OSS Watch workshop – Engaging developers with open source projects Gabriel spotted my post and decide to invite Mark to present. This turned out to be an excellent move as Mark’s presentation  The Line of Code That Could: Contributing to Moodle (pdf) not only complemented the other talks by Scott Wilson (Wookie) and Ian Boston (Sakai), but also made us aware of something important.

Mark’s presentation smoothly told the story of how he found a problem in Moodle when implementing a feature for use in his institution. He went on to explain the process he followed of engaging with the Moodle developer community and ultimately submiting a patch to fix it and that is now in the Moodle codebase. This is explored in depth in my previous post.

At the end of the event Ross did a round robin of ‘what did you get out of it’ and a handful said they would consider submitting their code to the relevant project community. This is a significant ‘win’ and even if only one person actually follows through we have a result to be pleased with. In our debrief we decided that Mark’s talk played an important part in achieving this positive outcome. I’ve identified the following reasons as key

  • By being a very small contribution and a ‘first’ contribution it presented an example that others could easily relate to. Especially those who have not yet contributed and who were the target  of this workshop. This contrasts with the other talks from the perspective of very experienced submitters (actually commiters).
  • Mark obviously enjoyed the process and the outcomes, including the kudos he gained.
  • While Mark made significant extra effort to engage and submit it was clear this had real value to him, his employers and to the Moodle community.

We’ll be looking for other ways use this realisation in our events and resources in order to encourage users and developers to engage more fully with their project communities.

Attend our developer workshop today from the comfort of your desk

We are live blogging our Engaging Developers with Open Source Projects Workshop today to allow those who cannot physically attend to follow the event.  You can watch the  live blog in your web browser (flash required) and are also able to ask questions or make comments.

Slides for the presentations of Mark Johnson (pdf), Ian Boston (pdf) and Scott Wilson are also available.

Strong leadership and openness = software sustainability

Time and time again we read and hear about how successful open source is maintained by an army of volunteers, yet those who are at the core of successful open source know this is not what makes the project survive in the long term.

For example, Greg Kroah-Hartman reported, in a Google Talk, that of 2399 unique contributors active on the Linux Kernel project during a year and a half, roughly 75% of the work was done by people who are paid to do so. All of those people are considered volunteers within the project, but they are not there for the good of their health (although open source work is often fun). Furthermore, half of those contributors only contributed a single patch, whilst thirty people (1.25%) do nearly a third of the work.

My own anecdotal evidence, collected from over 8 years of working in projects at The Apache Software Foundation, leads me to assert that the popular “army of volunteers” myth is a result of the chatter of the masses (the other 98.75%). In surveys, interviews and snapshot observations the one patch contributors far outnumber the visionary leaders in a project and as a result it is their voices and opinions that are heard. At the same time, the leaders know that they need to play down their own importance in order to credit the community, since the contributions of the community are vital to the survival of the project, I’ll look at why later in this post.

Dan Woods, in “The Myth of Crowdsourcing” appears to agree that leadership and vision is what is needed in a successful project:

There is no crowd in crowdsourcing. There are only virtuosos, usually uniquely talented, highly trained people who have worked for decades in a field…What really happens in crowdsourcing as it is practiced in wide variety of contexts, from Wikipedia to open source to scientific research, is that a problem is broadcast to a large number of people with varying forms of expertise…There is no crowd of open-source developers ready to attack every problem. In fact, most open-source projects are the product of one obsessed individual who wrote the software to meet his own needs. Often this individual was joined by other programmers who shared the founder’s vision and, under his direction, created great software.

However, I believe Dan, at least partially, misunderstands the importance of the crowd in crowdsourcing.

The real importance of community

The community is vital to the sustainability of an open project, and, increasingly as I’ll discuss later, closed projects too.Note that Dan talks about the “broadcasting of ideas”, this is where the “army of volunteers” comes into its own. They validate what is happening in the project, they fix bugs, make suggestions for improvements and provide sounding boards for new ideas. Without these contributions a project is completely reliant on a handful of individuals in leadership roles. This dependency presents two main problems.

The first is that the project relies on the limited knowledge of the leadership. Even the best of the best don’t know everything, or as Mark Twain puts it “to succeed in life, you need two things: ignorance and confidence.” An effective and successful leader has the ability to step back and listen to those with different experiences, make the right (or best) call and ensure it is actioned. That is, the best leaders encourage, support and reward an army of contributors so that their project continues to excel.

The second problem of this dependence on a small group of leaders is that things change. Over time, one or more of those leaders will move on. Where will their replacement come from? If the leaders have already cultivated an “army of volunteers” in an open and transparent way there should be no shortage of people willing and able to step up and take on the role.

What about closed development?

To ignore your community is a mistake in almost every case. Community and the power of crowdsourcing is not, as Dan explains, the sole domain of open source software. Open innovation is becoming increasing popular in most industrial sectors, including closed source software. Microsoft, for example, has its Most Valuable Professional programme which is specifically designed to:

recognize the best and brightest from technology communities around the world…These exceptional community leaders come from a wide range of backgrounds. They are teachers, artists, doctors, engineers, as well as technologists, who actively share their high-quality, real-world technical expertise with the community and with Microsoft.

Is openness for me?

Most people starting new projects assume that either their project is too specialised to be of interest to third parties or that opening up to the community will result in them being swamped by well meaning contributors. As a result, they don’t engage, support and reward their community.

Popular communities do not grow from one member to hundreds overnight, there is little chance of you being swamped. They grow organically and, assuming the community is empowered to self-govern under strong leadership, they grow in self-sufficient way. As for niche projects, an “army” of just one person can still be extremely valuable, who knows what just one person can do – after all, you are just one person, right?

If you care about software sustainability you should never ignore your community.

Pragmatic ‘virtuosos’

Message posted today on our social mailing list at work:

Do you lendaround ? Let me know if you sign up and I’ll email you an invite which’ll make it easier for you to connect into the network.

According to their website, Lendaround is a free web tool that aims to help people borrow things from one another. It’s good to bring friends, neighbours, families and colleagues together by swapping things, such as DVDs, isn’t it?

Why do such tools exist? Apparently, because somebody had an idea that made them sleepless in the first instance, and this person persuaded others to help make it happen:

Looking around his home, Tim noticed how much stuff we all seem to have that doesn’t get used very much — at a time when there are a billion people in the world who have not very much at all, and when it would be good to use a bit less of the earth’s resources.

The email message reminded me of a good read about The Myth of Crowdsourcing my colleague Amir pointed to me recently:

In the popular press, and in the minds of millions of people, the word crowdsourcing has created an illusion that there is a crowd that solves problems better than individuals. For the past 10 years, the buzz around open source has created a similar false impression. The notion of crowds creating solutions appeals to our desire to believe that working together we can do anything, but in terms of innovation it is just ridiculous.

The crowds by themselves, the author suggests, are unable to produce innovation. It is the highly skilled, highly motivated ‘virtuosos’ who are the real engines behind the often misused term crowdsourcing.

Open-source developers are often mentioned as a crowd of motivated programmers ready to meet the world’s software needs. A lot of wishful thinkers love to put forth the notion that all large software companies should be quaking in their boots because a crowd of open-source developers is ready to eat their lunch and create software for any purpose. There is no crowd of open-source developers ready to attack every problem. In fact, most open-source projects are the product of one obsessed individual who wrote the software to meet his own needs. Often this individual was joined by other programmers who shared the founder’s vision and, under his direction, created great software. Yes, there are large teams of developers on open-source projects, but without the virtuoso contribution at the outset, they would achieve nothing.

In OSS Watch consultations with HE projects we often need to correct the general view that open source is mainly the affair of a bunch of bearded geeks animated by common idealistic views. In fact, as mentioned in one of our workshop reports, the open development model that lays at the foundation of most open source commercial businesses is based on what Harvard Internet lawyer Yochai Benkler termed “commons-based peer-production”, a process by which everyone who contributes also gets something back that furthers their interests.

A certain level of pragmatism associated with the business of open source is perhaps not unrelated with the idea of the highly skilled ‘virtuosos’ that make crowds vibrate. Something worth exploring further, maybe in a break between watching two lendaround DVDs.