Author Archive for Ross Gardler

Apache Wookie (Incubating) and the W3C Standards

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:

Developing Communities

When I joined OSS Watch a couple of years ago my role was to enhance the community development work we undertake. I, and the rest of the OSS Watch team, have worked hard to understand how to build viable open source communities in the academic sector. Personally I can attest to having learned a great deal, yet it still surprised me when my colleague, Gabriel, reported on our recent trip to ApacheCon by saying that he observed me bringing community development lessons form my OSS Watch activity to the experts in the ASF.

I guess this is one reason why the ASF board recently approved a resolution to create a new Community Development project and appointing me as Vice President of Community Development. I look forward to this new activity in the ASF allowing me to further cross-fertilise between the ASF and the UK HE/FE sector, whilst the launching of a new EC project focussing on a wider engagement of computer scientists in open source projects will allow us to reach out to other software foundations.

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.

Software innovation in academic software outputs

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.

JISC Funding Call: Access & Identity Management

The Joint information Systems Comittee (JISC) in the UK have issued a new call for funding proposals titled “Access and Identity Management“. As with most JISC calls, proposals must come from UK educational institutions although other organisations can partner with appropriate institutions. Finding partners is one of the services OSS Watch offers as part of our bid writing consultation service (free to UK academic institutions).

As with all JISC calls, bidders are expected to consult with OSS Watch in order to understand how the JISC open source policy and the open development approach to project sustainability apply to their project (see paragraph 57 of the call details).

We look forward to helping you write your bids.