On the topic of diversity in open source software, I have a thought experiment - what if an open source project was structured more like a company? This is only a thought experiment, I’m definitely not advocating that we structure open source projects like companies, but I am looking for ways that we can improve diversity in OSS, and this is a big problem that many are struggling to find answers to.

The big difference between a company structure and an open source project structure is that in a company, there are many different roles, and each role has a number of responsibilities specific to that role. People are hired based on their competency to fulfill the responsbilities required by those roles. In contrast, an open source project tends to have only one role - the committer, and then all the responsibilities of the project are organically fulfilled by the various people who are in that role according to need and interest. When people are selected for the committer role, they are selected on broadly the same criteria, which is based on their technical contributions to the project.

Does this difference have any impact on diversity? Of course there is some impact, since each person in the committer role must have a passion for technical contribution to the project, whereas in a company structure, there will be some people with a passion for technical work in the technical roles, and other people with passion for communication in the marketing roles. But this is a lack of vocational diversity. The issue that we’re concerned about in the OSS world is not a lack of vocational diversity, it’s a lack of diversity of gender, age, race, sexual orientation, among other things. For lack of a better word, I’ll call this type of diversity “identity” diversity, as opposed to “vocational” diversity. At face value, if the pool of people that are passionate about technical contribution are diverse in identity, then there likewise should be identity diversity among committers in open source projects.

In practice we see things are not like this in open source projects. In contrast, and in my experience, big companies with a broad range of very specialised vocational roles tend to be very identity diverse - at very least outside of executive management. Also in my experience this identity diversity exists within vocational roles, it’s not just that each vocational role is filled with people of one type diversity that in aggregate makes the whole company identity diverse.

So could it be that a lack of diversity of roles - which are vocational based - fuels a lack in identity diversity in people that fill these roles? At this stage I haven’t done enough research to be able to answer this question, but perhaps it’s something that we could start experimenting with in open source projects.

§Putting it into practice

So if we were to try to introduce diverse vocational roles into open source projects, what roles would they be, and what would they look like? To make things a little more concrete, let’s start by thinking about the introduction of a marketing role. Every large open source project does a lot of marketing, from publishing blog posts to tweeting to organising conference engagements to engaging with the community on mailing lists. This is something that it would be quite straight forward to create a role for. This wouldn’t mean that everyone else in the project stops blogging/tweeting etc, that doesn’t happen in a company. It does mean that someone is given the responsibility of coordinating and ensuring that marketing happens.

In order for such a role to work, it needs to be well defined - open source projects are not used to having such roles, so it needs to be made clear to everyone on the project, not just the person in this role, what the responsibilities of the role are. This is necessary to empower that person to be and feel effective in the project. The responsibilities are going to vary from project to project, but in the context of my project, Play Framework, and without having put too much thought into it yet, this is what I’d envision:

• Be the public face of the project, the first point of contact for people that want to engage the Play community.
• Manage the Twitter account, including keeping an eye out for tweets to retweet and responding to mentions where necessary.
• Keep an eye out for community related questions on the mailing list, and respond or coordinate responses to those emails.
• Keep a look out for conferences that Play contributors, both in the core team and the broader ecoystem, could speak at, and link the appropriate people up with appropriate conferences.
• Write or coordinate project announcements, such as new releases, security vulnerabilities, etc.
• Seek ways to make Play a more attractive project to contribute to, through talking to people about their contribution experiences, and improving or coordinating improvements to documentation and the processes in place for receiving contributions.
• Seek ways to make Play an easier framework to get started with, through talking to people about their usage experiences, and improving or coordinating improvements to documentation and other resources.

Having defined the role, the next step is probably the hardest - finding someone to fill it. Finding people to fill a committer role of an open source project is generally easy, many developers that love using the software would also love to be a committer on it. Finding someone with skills and a passion for marketing who is willing to volunteer their time towards an open source project I would imagine would be a lot harder. This is possibly where my whole thought experiment falls down.

For Play though it’s not too hard to solve - Play is a project that is driven by a company, and that company already has a marketing team that does a lot of behind the scenes work in engaging the Play community. For us, we could make our marketing staff more public facing in the Play community, getting them to take on the responsibilities listed above (some of them they already do), and publicly acknowledging them as a member of the Play community, not just a member of the Typesafe marketing team, on the Play website. This may be a good start.

This is just one role that we could look at introducing to open source projects. There are many other possible roles, including leadership roles (in most companies these are not filled by technical people), product management, and a variety of HR roles. I’m not sure how well (if at all) these will work in an open source project, but in order to improve diversity, OSS projects are in need of big changes, and whatever changes are found to work will probably appear unworkable at first. So I think these are worth trying.

A few days ago a panel of four men showed the world that they had no clue about the issues that women in tech faced, and how they should be solved. The overwhelming theme that I picked up from the criticism that I read about it was “you’re not listening to us”. Is that true? Are these male industry leaders really not listening to women? I mean surely they have read the accounts of the issues that many women in tech have faced, isn’t that enough?

Now I am about to break one of the cardinal sins of talking about women in tech - relating it to my wife - but please bear with me, it’s not what you think. My wife Beth and I are currently getting marriage counselling¹. In it we have rediscovered two things that we always knew but need to keep being reminded of. The first is that during conflict, Beth speaks using emotional language. The second is that during conflict, I speak using logical language. In order for us to resolve conflict, we need to speak each others language, I need to talk more about how things make me feel, and Beth needs to step back from her feelings and reason logically about hers and my actions.

It is from this difference in languages that the problems of women in tech flow. No! That’s not it at all. But, if you’re a man, you may have been nodding your head as you read that statement. If you’re a woman, if it weren’t for the no in bold text immediately after that statement, you probably would have closed your browser in anger. And this highlights a deep problem.

We men have a tendency to approach the things that women are saying - the accounts of harassment and abuse, the accounts of every day prejudice, and the calls to action - as if those women speak a different language, the way our wives/mothers/girlfriends do. But read some of the accounts again. Are these spoken with a language of emotion? They certainly talk about emotion, but those accounts are very well reasoned and logical texts that speak plainly about actual events. Even if, and that is a very big if, the women who told these accounts do have a tendency to use emotional language over logic and sound reasoning, they have clearly mastered the skill of communicating to men - after all, in this industry, they have to.

So what is the impact of this approach that we men take, and what do I mean by it? When I first read Julie Ann Horvath’s account of her experience at GitHub, my subconscious immediately told me that I had to be careful. Women have a tendency to overreact, to speak with a language of emotion that does not follow sound reasoning or logic, and I should take the things that I am reading with a grain of salt. Any reaction that I have to this I should carefully measure, I should refrain from saying anything too strongly about it, in case it turns out not to be true. While I believed that it probably was true, I let my subconscious prejudice stop me from taking it too seriously.

This reaction doesn’t make sense. But the deep impact that it has is that it causes me to distance myself somewhat from the problem. And while in certain circumstances distancing yourself from problems does little harm, in this instance, it is the worst thing I could possibly do. Why? Because what if the problem is me? If I distance myself from the problem, I will never see that it’s me.

No wonder women are complaining that men are not listening. As long as we approach women as a group that speaks a different language, we will never listen to them. We will never understand what they have to say. We will distance ourselves from their arguments, and from the implications, and this means, if there is any problem in us, any implication that should change us, we will not hear it.

It has taken me a long time to learn this. I used to think that the issue of women in tech was just some gripe over numbers, that the problem was that the number of women in tech didn’t equal the number of men in tech, and that some vocal women believed that that needed to be fixed. As I’ve read more and more and more accounts of women facing sexual harassment and discrimination I’ve slowly come to understand that it is something very different. I should have listened earlier, and come to this conclusion a long time ago. But better late than never. I’ve come to the conclusion that the issue of women in tech is a man’s problem.

§It’s a man’s problem

The only person that can change your attitudes is you. Other people can’t change them - they can point you in the right direction, they can present you with well reasoned arguments on why you should change and how to change, but at the end of the day, the only person that can change them is you. The women in tech issue comes down to the attitudes of us men, and therefore it is a problem that only we men can fix. This is what I mean by it’s a man’s problem - the changing will be done by men.

However, the initiative to fix it must be led by women. Why? Because only women can explain how they are prejudiced against, how the actions of men, particularly the small seemingly inconsequential ones that happen every day, impact women. They are the ones that see and experience the problem, and so they are the only ones that can describe and instruct on how to remedy the problem.

But the main force of change must come from men that are listening to these women. Men who are not just reading the accounts and remedies, but are actually listening to them without prejudice. These men have two tasks:

1. Change themselves. When women identify something that men are doing that is harmful to women’s acceptance in the IT industry, men need to examine themselves to see if they are exhibiting that action, and if so, change it.
2. Convince other men to listen to women without prejudice. This is a job that must be done by men, because if the men that need convincing aren’t listening to women, then nothing a woman says will resound with them.

If you’re a man reading this, and you think “after reading this I now understand the issues that women in tech face”, then you’ve missed the point. I don’t understand the issues that women in tech face, so there’s no way after reading something that I’ve written that you could understand them. I’ve merely pointed out the first step - to start listening to women without prejudice. The next step is to actually listen to them! Read the blog posts and news articles of the accounts of women in tech with unprejudiced eyes. Talk to your female coworkers and friends about the issues they face, and listen to them. Attend conferences and meetups aimed at promoting women in tech, and listen! This is a man’s problem that requires action by men, and the first step is listening to women.

§Footnotes

1. No, our marriage is not on the rocks. Beth and I believe that a marriage is like a car, and marriage counselling is like a mechanic. If you wait until a car breaks down before you take it to the mechanic, it will have a much bigger impact and cost a lot more to fix - it may even get written off. Rather, you take the car to the mechanic for regular checkups while it's healthy. Likewise, waiting till a marriage breaks down to see a marriage counsellor is likely to cause a lot of pain and take a very long time to fix. Rather, seeing a marriage counsellor while your marriage is healthy ensures the long term health of the marriage, and also ensures that you both get the most out of the marriage too. We see the marriage counselling we're getting now as our 5 year checkup.

Today I migrated my blog to a new blogging engine that I’ve written called ERQX. Now to start off with, why did I write my own blog engine? A case of not invented here syndrome? Or do I just really like writing blog engines (I was, technically still am, the lead developer of Pebble, the blog that I used to use)?

I was very close to migrating to a Jekyll blog hosted on GitHub, but there are a few reasons why I didn’t do this:

• As a full time maintainer of Play, I don’t get a lot of opportunities to use Play as an end user. This is bad, how can I be expected to guide Play forward if I don’t feel the pain points as an end user? Hence, I jump at every opportunity I can to write new apps in it, and what better use case is there than my own blog?
• I really like the setup we have with the documentation on the Play website - we have implemented some custom markdown extensions that allow extracting code snippets from compiled and tested source files, and all documentation is served directly out of git, which turns out to be a great way to deploy and distribute content.
• I wanted to see how easy it would be to make a full reusable and skinnable application within Play.
• Because I love Play!

§Features

So what are the features of ERQX? Here are a few:

§Embedabble

The blog engine is completely embeddable. All you need to do is add a single line to your routes file to include the blog router, and some configuration in application.conf pointing to a git repository, and you’re good to go.

Not convinced? Here is everything you need to do to include a blog in your existing Play application.

1. Add a dependency to your build.sbt file:

   resolvers += "ERQX Releases" at "https://jroper.github.io/releases"
   
   libraryDependencies += "au.id.jazzy.erqx" %% "erqx-engine" % "1.0.0"
   

2. Add the blog router to your routes file:

   ->  /blog       au.id.jazzy.erqx.engine.controllers.BlogsRouter
   

3. Add some configuration pointing to the git repo for your blog:

   blogs {
     default {
       gitConfig {
         gitRepo = "/path/to/some/repo"
         remote = "origin"
         fetchKey = "somesecret"
       }
     }
   }
   

And there you have it!

§Git backend

In future I hope to add other backends, I think a prismic.io backend would be really cool, but for now it just supports a git backend. The layout of the git repo is somewhat inspired by Jekyll, blog posts go in a folder named _posts, named with the date and title in the name, and each blog post has a front matter in yaml format. Blog posts can either be in markdown or HTML format. There is also a _config.yml file which contains configuration for the blog, such as the title, description and a few other things.

Changes are deployed to the blog either by polling, or by registering a commit hook on GitHub. In the example adove, the url for the webhook would be http://example.com/blog/fetch/somesecret. Using commit hooks, blog posts are published within seconds of pushing to GitHub. ERQX also takes advantage of the git hash, serving that as the ETag for all content, allowing caching of the blog and its associated resources.

§Markdown

Blog posts can be in markdown format, and uses the Play documentation renderer to support pulling code samples out of compiled and tested source files. This is invaluable if you write technical blog posts full of code and you want to ensure that the code in the blog post works.

§Themeable

The blog is completely themeable, allowing you to simply override the header and footer to plug in different stylesheets, or completely use your own templates to render blog posts.

The default theme uses a pure CSS responsive layout, switching to rendering the description of the blog in a slideout tab on mobile devices, and provides support for comments via Disqus.

§Multi blog support

ERQX allows serving multiple blogs from the one server. Each may have its own theme.

§Source code and examples

ERQX and its associated documentation can be found on GitHub.

The website for this blog, showing how the blog can be emedded in a real application, plus the content of the blog itself, can also be found on GitHub. The website is in the master branch, while the blog content is in the allthatjazz branch.