It has been oft stated that diversity is key for the Open Source community to develop. You don’t have look far to see how diversity plays a key role in software development and community infrastructure construction. We demand not only diverse skill sets (artists, developers, documentation writers, usability engineers, musicians etc.), but also diverse levels of opinion, culture and philosophy. With our community ingrained in a distributed web of network-connected people, we have had to respond and mobilise to culture so as to ensure that a western majority does not dominate the entire offering. As such, our software is localised in a huge number of languages, it takes account of subtle cultural differences, and the average Open Source developer works with such diversity on a daily basis.

Although things are bright and rosy on one level, diversity also brings its own collection of challenges and difficulties, and some of these problems have not been solved yet. I want to focus on two areas in this post – diversity at the project level, and diversity at the human level.

## The project level

At the project level, diversity is essential in all but a few projects. Traditionally, diversity was “choice within a relatively restrictive persona”. This manifested in debates about vi vs. emacs or KDE vs. GNOME. Many onlookers heralded this as a new era of software choice and diversity. Sure, we have choice, but what I am getting at is *real* diversity at a project level, not just technical decisions.

Since my introduction to Open Source just under 10 years ago, I have worked on a range of projects, and each has had their own levels of diversity required. As an example, Linux UK demanded diversity of journalistic ethics as well a technical team to build the site and ensure it was well developed. LUGRadio regarded a different type of diversity as the community was constructed, and today, Jokosher needs an entirely different approach.

Diversity is *not* just about getting people with different skillsets involved in a project. It does not manifest in just having nice icons, well written documentation or solid code. It is not just about having different packages, a translated website or a frappr map with users from around the world. These elements form part of the diversity challenge but there are many other issues at play also.

The challenge of diversity is the ability to bring into a project different types of expertise, optimise their contributions, define solid milestones, develop autonomy and refine inter-skill communication. The goal of diversity is similar to the goal of good design an usability – to define an eye for detail, and back that up with good practise, solid implementation and the ability to measure progress efficiently. It all boils down to an ability to understand the importance and severity of different aspects of an application/project and never minimise that importance where it should be raised. As an example, the importance of good design and usability often gets overlooked in many projects, so does the importance of consistent icons, strong documentation and ease of use. These issues are typically seen as secondary to piling in the features, revving quickly and creating ‘cool new stuff’.

The prioritisation problem is born of natural human instinct – to refine and prioritise those skills that are (a) easily accessible or on tap and (b) are just plain fun to work on. To ensure these different aspects get the respect and importance that they deserve, it demands a higher level approach and someone with an oversight orientated approach to the project. This person essentially acts as a community manager who ensures that the wheels are oiled in each of the different teams, and works to encourage, inspire and foster development in each of the different parts of the project. We have people doing this in a range of projects, and this has been my role in the Jokosher project. I am not in charge, but I work to ensure we can get the most out of our different teams.

The key here is actually having those teams in the first place. Sure, we are a small project, and our teams all number less than 8 participants, but each team has its own direction, culture and social structure. If you take our art team as an example, Oscar is leading the team, and he is working with the other chaps to define a best practise for Jokosher art. There is a little sub-culture working there, and it can only mean better art for Jokosher. I have been working to develop a bunch of teams like this, and they are really getting on their feet and doing some great things, and with the recent i18n code in Jokosher, I am also working to build a [Translation Team](https://jokosher.python-hosting.com/wiki/TranslationTeam). Apply within…

Although constructing these different teams is one aspect of building a diverse community, the real key is how the teams work together. This boils down to interoperability, advocacy and a common culture across the entire project. Since the beginning of the project there has been a strong culture of openness and regular feedback. There has also been a culture of separating skills into the different autonomous teams, but ensuring there is a strong project-wide connection. This is why there is a single [Jokosher mailing list](). If we had multiple lists it would fragment the community – we instead want each team to feel like a unit, but to integrate well into the bigger picture with as little red tape as possible. Part of the reason why it has been so useful to have an oversight over the entire project is that there is someone fairly unambiguous to help foster these connections. This is all about best-practise, and best-practise isn’t about putting rules in place and forcing people into boxes.

## The people level

I have been thinking a lot about diversity at the people level recently, partially sparked by the interesting talk given by *The Women Of LUGRadio* at LUGRadio Live. The talk looked at why women may get a less than equal experience when coming into the Open Source or IT industry, and how we can smooth these problems. Three prominent members of the LUGRadio community (Kat, Jen and Phated) gave the talk, and it caused some great discussion. I am pleased to see that Jen is following this up and looking to spread the message and do some interesting things. I think the important thing to focus on here is first how we identify how prejudice affects different groups, and secondly how we go about solving the problem.

I am not going to go into all the details of prejudice and my opinions and thoughts around it, but I think there needs to be a strong sense of grounding to the discussion. From what I can see, most of the problems that women have identified when coming into the community are problems *not specific* to women, but also other groups. I am sure many readers of this blog have experienced some kind of prejudice due to colour, creed, age, sex, accent, political persuasion, sexuality or other areas. Sure, women are affected by many of these issues, but this is a bigger problem with prejudice, and we need to be careful not to zone in on one group affected and not the others.

Bringing it back to diversity, I think we need to identify how different groups of people can again bring different benefits, value and perspective to the community. I am keen that we should not be afraid of our differences for fear of being offensive or putting someone in a group, but we need to encourage areas in which we can bring value. The key here though is in not dissuading people from the community just because of who they are – lets encourage a women to participate because of her particular skills, but whether or not she uses those skills, lets not outcast her because she is a women. And, importantly, we need to encourage adoption and integration into our existing community and not develop splinter groups. The [GNOME Womens Outreach](https://www.gnome.org/projects/wsop/) programme does this perfectly – it encourages women into an existing diverse community, as opposed to creating a separate community just for women who want to contribute to GNOME. This is the right way to do things.

I am keen to get everyones thoughts on this – do leave your comments. 🙂