Archive for the 'Software' Category

GNOME and Project:Possibility: collaboration in open source accessibility

Published by stevelee on March 14, 2010 in Community, Development and Software. 0 Comments

In my last post I mentioned how satisfying it is to watch the results of making introductions between people or groups. Recently I was involved in a link up between students and GNOME accessibility and though I’d explain how events panned out, as well my hopes.

Project:Possibility organise team coding competitions for computer science students. The the goal of these SS12 events is to create accessibility software that will be of benefit to real users. These weekend ‘code-a-thons’ bring the students together with a mentor from industry and provide an exciting chance to learn something about accessibility, while creating open source software. Thus students get exposure to topics and skills that are still sadly absent from many computer science courses. Plus they get to have fun and win prizes.

Project:Possibility was set up by Chris Leung while he was at USC so it is fitting that the latest SS12 was a face off between USC and rivals UCLA. This added an extra element of competition, and the winning team from each campus have been invited to present their work at the 25th CSUN conference (#csun10) next week. They also get the opportunity to explore the conference, getting a flavour of the many accessibility offerings. CSUN have been very supportive of Project:Possibility and are keen to see students learn about accessibility and take the knowledge along with them as they start their careers.

The Project:Possibility board decided to concentrate our energy on the weekend competitions, at least for the short term. While accessibility is clearly a key feature of the events, I felt the experience of open source is less compelling. The code is given a open source licence and placed on Google Code but there is not much opportunity to provide an in depth experience of open development or to support subsequent maturing of the new software. OSS Watch are very aware that employers are seeking open source development experience, and yet there is a shortage of skills as they are not often being taught in computer science course. This further influenced my thinking.

I have previously worked with the friendly and hard working GNOME accessibility community, so I therefore proposed that we offer students the opportunity to work with them. The idea was to support students in adding features to existing GNOME accessibility projects, working with community members. This would introduce students to the project, hopefully exposing them to best practices. My hope was also that this introduction will lead to longer term engagement with GNOME accessibility or other projects and continuing contributions. Some concern was voiced that students would not want to climb the extra learning curve while competing in a weekend event. The GNOME team, however, were supportive of the idea and we all hoped the right students might be ‘up for’ the greater challenge and potentially greater rewards. We came up with a few coding ideas and I’m pleased to say a team from each of USC and UCLA chose to work on GNOME Caribou, the new GNOME on screen keyboard that provides operation for non keyboard users (via pointer, switch or other devices).

Ben Konrath, the Caribou lead, was available on IRC during the competition and answered questions from the students, helping them to get up to speed. With his help, both sets of students got through to the finals and came 2nd and 3rd place overall. Ben will now help the students go through the submit and review process and hopefully commit their code into Caribou. From there it will be part of GNOME and so will appear in many Linux distributions. Something the students can rightly be proud of.

If you are interested in seeing what the USC students have done with Caribou then you can meet the teams at CSUN next week on 26th and 27th. There is already considerable interest in the students work, including from Microsoft. CSUN have promoted their attendance in conference announcements, and this has also raised GNOME accessibility profile, not bad seeing it is their fist year at the conference. If you would like to find out more about GNOME open accessibility the team are there all week at the booth.

I’m really looking forward to the conference, catching up again with GNOME (and Mozilla), meeting the students and, hopefully, hacking a little on Caribou. I hope to see you there.

Governance Models – everything you wanted to know but where afraid to ask

Published by stevelee on February 18, 2010 in Community, Development, Software and Strategy and Policy. 0 Comments

After an extensive gestation period, OSS Watch are pleased to have jointly published 3 documents on the important subject of Governance Models for open source projects. That is excellent value for your money.

The documents on our web site undergo a rigorous quality assurance process that ensure they are technically correct and well scribed. The result in this case is an comprehensive introduction to a topic that can be over looked by projects, or may cause confusion and uncertainty.

I have on several occasions heard lead developers say that if they make their code open source they fear they will loose control and anyone can update their source, leading to chaos. As you read these documents you will see that this clearly should not be the case. The project leaders remain in control, in fact they make the decisions on who the leaders are and how the project is controlled. The governance model describes how this happens.

Having a governance model in place is one of the clear marks of an open source project that practices open development. That is, it marks a project that positively encourages community engagement.

Governance models provides an introduction to the what, why and wherefore of managing an open source project.

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. It is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Meritocratic governance model provides a detailed insight into this common model that is lead by an elected leadership team or ‘board’. A template is provided for use by projects interested in applying this model.

The meritocratic governance model is a commonly found model in which participants gain influence over a project through the recognition of their contributions. The Apache Software Foundation (ASF) is perhaps the most famous example of a large-scale meritocratic community. The foundation operates with an almost completely ‘flat’ structure, which means that anyone willing to contribute can engage with their projects at any level.

Benevolent dictator governance model describes another popular model where one person leads the project and has a final say in decisions. Again a template is provided for projects wanting to use this model.

A benevolent dictatorship is a project controlled by a single leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel project, which is run under the direct decision making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective.

With any project, good leadership or management are vital, and these documents will help you install the basics with little overhead. If your project already has a governance model in place then these documents could help you refine it, perhaps by making it explicit. If you don’t yet have one, then these document will help you decide what model best suits your style, and quickly get it into operation.

And you can do it all without any sign of pointy hair.

GNOME accessibility – the future

Published by stevelee on February 11, 2010 in Community, Development and Software. 1 Comment

The layoff of Willie Walker by Oracle is causing consternation in the the open source accessibility world, and for good reasons. As lead of GNOME accessibility and head developer of the Orca screen reader for the blind, Willie is a key member of GNOME accessibility. GNOME itself is a key player in the open accessibility field. The recent OSS Watch briefing note on open accessibility identified the importance of GNOME’s position and it’s contribution under the leadership of Willie.

Until this fallout from the recent takeover of Sun by Oracle, Willie was employed by Sun to work full-time on GNOME accessibility. The removal of Willie’s salary has removed a critical source of funding for open accessibility and the community is reeling as a result.

However despite the understandable concerns for the future of both Willie personally and GNOME accessibility, this is also a opportunity for both. People like Willie are highly sought after by employers who value leadership skills coupled with excellent technical experience. A couple of people described Willie as the Linus of open accessibility, a simile that has some merit. We can hope his next employer (or funder) will allow him to further develop his passion for accessibility, building on his impressive legacy to date.

For the GNOME and open accessibility communities, the impact of this seemingly crass business decision also causes us to focus hard. It can be a catalyst for improving the sustainability of this small but effective community as Willie himself indicates. I’d like to explore the subject a little in this post.

In general people get involved in open source for selfish reasons. These may be personal needs, corporate motivations or academic interests. The power of open development comes from working together to develop and maintain a common resource that benefits all players. The famous phrase is ’scratching an itch’. When it comes to open accessibility, however, there is an extra dimension. While many members of the community are users of accessibility, others are not and are involved for more complex reasons like social concern, if not quite altruism. This leads to members being in a position of “scratching another person’s itch”. There are elements of accessibility being a basic human right and these colour the community relationships and explain some of the strong outraged reactions to Willie’s layoff. As an aside it’s worth recalling Sun’s significant contribution to accessibility, something that was obviously not core business for them.

The fact that community members are in it for largely selfish reasons means they are likely to leave for equally selfish reasons. There should be no surprise at that. The key is to develop a broadly diverse community that can sustain any individual member’s exit. This is the opportunity I see we now have. I hope that Willie will continue to work full-time but I also hope we will work hard to attract more members who will also bring resource with them. Many of the reactions have vocalised the need to find funding but I feel we should focus on building the community first and the funding will follow. We also need to build community as, to be frank, there is a huge amount of work to be done, as can be seen on the GNOME 3.0 accessibility roadmap.

That might sound rather glib and the question is how can we move forward and encourage? Building community is difficult and not a science but there are many good examples to learn from. I’m fortunate to work for OSS Watch who’s key message is open innovation through community. Ross Gardler our service manager is also Vice President of Community Development at The Apache Software Foundation. The Foundation are also highly experienced in community development. Their informal moto is ‘Community over code’ and most of their activity is community building. For example the Apache Incubator helps projects develop their community and graduation requires at least 3 independent comitters to have joined. So there is a wealth of experience available to tap into and I’d like to see how the open accessibility community can use this to become more sustainable.

On to some practicalities. We are already seeing signs of the community dusting itself down and moving on. Eitan posted yesterday on further plans for the GNOME accessibility ‘hackfest’ at the CSUN accessibility conference. CSUN is THE accessibility conference and this year GNOME joins Mozilla in having a booth. This is the perfect opportunity to introduce GNOME’s work to the #CSUN10 visitors and encourage users and companies to engage. If you are going to CSUN be sure to find the booth and meet the team. The hackfest is the place for other developers to come along and learn what the code looks like and what needs doing. If your are a GNOME, KDE, Linux or Linux Mobile developer you should look us up to find out how to make your program accessible or how to work on accessibility programs.

This year the winners of Projects:Possibility’s SS12 open accessibility coding competition have been invited to attend CSUN. They will look around and present their winning projects. Accordingly computer science students from CSUN, UCLA and UCS will be able to learn about GNOME accessibility and find how they can engage in the action. At a minimum they will take their knowledge of GNOME to their future employers.

In a couple of weeks the GNOME Usability hackfest is in London and overlaps with the Dev8D developers days event. Cross fertilisation is planned and given that accessibility may be viewed to be a part of usability there is another opportunity to explore how to support GNOME accessibility.

OSS Watch have developed a tool that will be useful for exploring the sustainability options for GNOME accessibility. It’s part of our forthcoming Software Sustainability Maturity Model and provides a Q & A on the areas that need to be be covered in order to reach open sustainability. I encourage community members to try it on their project or the community as a whole. It will help focus on the the gaps and provide a common language for discussion of the solution. The form provides detailed explanations and the results are presented as percentages. If you are not sure just leave it as “don’t know”. Results are likely to be cleared at some point, so if you want to keep them drop us a line and we will provide a copy.

So in summary the news of Willie’s layoff is a source of considerable concern for him personally as well as the GNOME accessibility and the wider communities. It is also an opportunity to move on and develop new strengths through open development. The community has previously survived funding loss (IBM) and a key player leaving (Bill Haneman). As Willie says in his email – spread the word far and wide. The time is good as there is not only growing interest in open source in general but also a widening awareness of the benefits of open accessibility. If you are a member of the community then you can start thinking about how to reach out. If you are not yet a member then do introduce yourself at one of the events or on the lists or IRC.

Software Developers for Haiti

Published by Ross Gardler on January 22, 2010 in Community, Development, Discussion and Software. 1 Comment

Some time ago I posted “Does it take a disaster to understand the power of open development?” Unfortunately it is now time to revisit that post with a call for software developers to help Haiti.

The Sahana Software Foundation are looking for additional developers to help with Sahana, a disaster management tool. They need to continue to build an information portal that is seeing increased interest and usage to assist organisations responding to events in Haiti. Information on the work underway can be found on the Sahana Haiti response Overview page.

The skills they are primarily looking for are (you don’t need them all, any will do):

  •  Python – the main development for SahanaPy is Python (we’re not using PHP for this instance)
  •  web2py – Sahana uses the web2py enterprise framework for SahanaPy (I’m told it is fairly easy to learn if you’re used to Django)
  •  OpenLayers
  •  jQuery

To find out more and offer your help please jump onto #sahana on freenode. Please give as much or as little as you want.Some of the core devs have been working really long hours the past 5-6 days, and any additional resource would assist us greatly, particularly as the effort is really starting to get some interest, traction and coverage, which leads to more and more feature requests.

Thanks for reading this far – please consider giving a few hours of your time to help out, if you can.

TechDis Accessibility Toolbar features open development

Published by stevelee on January 19, 2010 in Community, Development and Software. 0 Comments

The recent launch of the new JISC TechDis toolbar sees the introduction of an accessibility tool for students and others when accessing the web. This replacement for the previous TechDis toolbar increases the accessibility of almost any web site by running directly in popular web browsers, and provides features like text to speech of page content.

One important feature that may not be obvious from using the toolbar, is that the Accessibility Team at the University of Southampton Learning Societies Labs, developed the toolbar for TechDis while also making it an open source project.

By supporting this TechDis have increased the opportunity for sustainability by allowing the project to continue to evolve while attracting contributions from others, whether they are users submitting bugs and feature requests, or development teams interesting in using it in new applications. OSS Watch’s advise on open development practices has enabled EA Draffan to include these in her management of the project. In addition Seb Skuse, the lead developer, has used established open practices in his daily work on the project.

Seb attended one of the OSS Watch workshops on engaging with open source and found what he discovered useful in ensuring barriers to contribution are been minimised. The Accessibility Team have been heard to say that they enjoy working on an open source project and I am impressed with their eagerness to understand and apply the principles.

Working with them has been a very positive experience. They are undoubtedly a group to watch as they steadily increase their portfolio of open accessibility projects with wide application. Tools that demonstrate open innovation in provision for users of accessibility in education and beyond, by turning new ideas and research into solutions which provide practical benefits.

Download and try the Toolbar and let the team know what you think. You will find the team most welcoming of your ideas or other contributions.

Enjoying the rewards of open development

Published by stevelee on November 14, 2009 in Community, Development and Software. 0 Comments

We’ve been advising EA Draffan and Seb Skuse at University of Southampton School of Electronics and Computer Science (ECS) on opening up the development of their StudyBar accessibility project. The development of this suit of accessibility tools for learners using the web is being funded by JISC TechDis as a replacement for their current web accessibility toolbar. Technically there are some interesting challenges, particularly the decision to support several browsers on various platforms. These technical complexities, the need for wide testing, and the varied user requirements and experiences are well matched to open development, which allows interested parties to bring resource to the project.

A concern we often hear voiced about open development is that it might involve a lot of extra effort when working with other people. In the case of Study Bar, Seb certainly has his work cut out as sole developer, and EA is busily involved in managing other accessibility projects. So what has been their experience after they took our advice and made initial steps towards open development? Initial steps that involved the introduction of a website (blog), issue tracker and code repository (Google Code) and a mailing list (Google Group).

EA had this to say after several users provided feed back on the the list:

It has been such a good idea having this list and Seb and I were just
saying how useful it will be for any future FAQs that could be made
into a web page

EA then expanded on this:

I really do think the way we have managed to get the group going and all the bug checking has really helped us speed up the process so much. It has been really useful!

This experience is not unusual, as projects find the value added by open development exceeds any extra cost. Providing easy access to code, tickets and project memory in the form of discussions and decisions, enables participants to be fully informed without constant questioning of the project members. This means interactions can be focused on adding value for all parties.

So while setting up and using these community tools is only the first step, the Study Bar team have already see benefits. OSS Watch will continue to guide them along the path towards fully embracing open development. The goal is to maintain a diverse community of users and developers, a community that provides requirements, resource, that encourages innovation and reaches sustainability.

I have been invited to explain the use open development to others at Southampton in a LSL seminar next week and I’m looking forward to helping others make the first steps. We will also be holding a workshop on Dec 7 in Oxford that explores community building in more detail.

Meetup on the Apache Wookie project

Published by Sander van der Waal on October 29, 2009 in Community and Software. 0 Comments

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

Published by stevelee on October 14, 2009 in Software, Standards, Strategy and Policy and Uncategorized. 0 Comments

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

Published by stevelee on October 13, 2009 in Community, Development, Event and Software. 0 Comments

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.

Strong leadership and openness = software sustainability

Published by Ross Gardler on October 2, 2009 in Community, Development, Software and Strategy and Policy. 1 Comment

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.