As reported in
Ars Technica,
the ongoing efforts to promote diversity in open source communities came
up once more during the plenary Q&A session with Linus Torvalds, Andrew Tridgell,
Bdale Garbee and Rusty Russell.

I was there for that session, and found that Linus's response appeared to
betray a fundamental misunderstanding of the motives of many of the folks
pushing for increased diversity in the open source community, as well as a
lack of awareness of the terrible situations that can arise when leaders in a
community regularly demonstrate abusive behaviour without suffering any
significant consequences (just ask folks like Kathy Sierra, Zoe Quinn, Anita
Sarkeesian and Brianna Wu that have been subjected to sustained campaigns of
harassment largely for being women that dared to have and express an opinion
on the internet).

As the coordinator of the Python Software Foundation's contribution to the
linux.conf.au 2015 financial assistance program, and as someone with a deep
personal interest in the overall success of the open source community, I feel
it is important for me to state explicitly that I consider Linus's level of
ignorance around appropriate standards of community conduct to be unacceptable
in an open source community leader in 2015.

Linus's defence of his abusive behaviour is that he's "not nice", and
"doesn't care about you". He does care deeply about his project, though,
and claims to be motivated primarily by wanting that to continue to be
successful.

To be completely honest, the momentum behind the Linux juggernaut is now
large enough that Linus could likely decide to chuck it all in and spend the
rest of his life on a beach sipping cocktails without worrying about open
source politics, and people would figure out a way to ensure that Linux
continued to thrive and grow without him. Many a successful start-up has made
that transition when the founders leave, and there's no good reason to believe
an open source community would be fundamentally different in that regard. The
transition to a new leadership structure might be a little messy, but the
community would almost certainly figure it out.

However, there's still a lot of scope for Linus to influence how fast Linux
grows, and on that front his words and actions suggest that he considers
being careless in his speech, without regard for the collateral damage
his verbal broadsides may be doing to his cause, more important than
having the most positive impact he is capable of having on the future growth
of the Linux kernel development project and the open source community at
large.

It's not (necessarily) about being nice

It may surprise some folks to learn that I don't consider myself a nice human
either. My temper is formidable (I just keep it under control most of the
time, a task online communication makes easier by providing the ability to
walk away from the computer for a while), and any feelings of compassion I
have for others are more a product of years of deliberate practice and
hanging around with compassionate people than they are any particularly
strong innate knack for empathy.

I'm pretty sure that genuinely nice people do exist, and I assume
that one of their key motives for creating open, welcoming, inclusive
communities is because it's fundamentally the right thing to do. The main
reason I exclude myself from my assumed category of "nice people" is that,
while I acknowledge that motivation intellectually, it's not really one that
I feel viscerally.

Instead, what I do care about, passionately, is helping the best ideas win
(where I include "feasible" as part of my definition of "best"). Not the
"best ideas from people willing to tolerate extensive personal abuse".
The best ideas anyone is willing to share with me, period. And I won't hear
those ideas unless I help create environments where all participants are
willing to speak up, not just those that are prepared to accept a blistering
verbal barrage from a powerful authority figure as a possible consequence of
attempting to participate. Those are upsetting enough when they come from
random strangers on the internet, when they come from someone with enormous
influence not only over you and your future career, but also your entire
industry, they can be devastating.

The second order consequences

So there you have it, my not-nice reason for advocating for more welcoming and
inclusive open source communities: because, from an engineering standpoint, I
consider "has a high level of tolerance for receiving personal abuse from
community leaders" to be an extraordinarily stupid filter to apply to your
pool of potential contributors.

Exhibiting abusive behaviour as a leader has additional consequences though,
and they can be even more problematic: by regularly demonstrating abusive
behaviour yourself, you end up normalising harassment within your community
in general, both in public and in private.

I believe Linus when he says he doesn't care about who people are or where
they're from, only their contributions. I'm the same way - until I've known
them for a while, I tend to care about contributors and potential
contributors wholesale (i.e. happy people that enjoy the environment
they're participating in tend to spend more time engaged, learn faster,
produce superior contributions, and more quickly reach the point of being
able to contribute independently), rather than retail (i.e. I care about my
friends because they're my friends, regardless of context).

But when you're personally abusive as a leader, you also have to take a high
level of responsibility for all the folks that look up to you as a role
model, and act out the same behaviours you exhibit in public. When you reach
this point, the preconditions for participation in your community now include:

Willing to tolerate public personal abuse from project leaders

Willing to tolerate public personal abuse from the community at large

Willing to tolerate personal abuse in private

With clauses like that as part of the definition, the claim of "meritocracy"
starts to feel a little shaky, doesn't it? Meritocracy is a fine ideal
to strive for, but claiming to have achieved it when you're imposing
irrelevant requirements like this is arrogant nonsense.

We're not done yet, though, as this culture of abuse then combines with
elitism based on previously acquired knowledge to make it normal to abuse
newcomers for still being in the process of learning. I find it hard to
conceive of a more effective approach to keeping people from adopting
something you're giving away for free than tolerating a community that
publicly abuses people for not magically already knowing how to use
technology that they may have never even heard of before.

As a result of this perspective, the only time I'll endeavour to eject anyone
from a community where I have significant influence is when they're actively
creating an unpleasant environment for other participants, and demonstrate no
remorse whatsoever regarding the negative impact their actions are having on
the overall collaborative effort. I count myself incredibly fortunate to
have only had to do this a few times in my life so far, but it's something
I believe in strongly enough for it to have been the basis for once deciding
to resign from a position paying a six-figure salary at a company I otherwise
loved working for. To that company's credit, the abusive leader was let go
not long afterwards, but the whole secretive corporate system is rigged such
that these toxic "leaders" can usually quickly find new positions elsewhere
and hence new subordinates to make miserable - the fact that I'm not willing
to name names here for fear of the professional consequences is just one more
example of how the system is largely set up to protect abusive leaders rather
than holding them to account for the impact their actions have on others.

Ideas and code are still fair game

One of the spurious fears raised against the apparently radical notion of
refusing to tolerate personal abuse in a collaborative environment is that
adopting civil communication practices somehow means that bad code must
then be accepted into the project.

Eliminating personal abuse doesn't mean eliminating rigorous critique of
code and ideas. It just means making sure that you are critiquing the
code and the ideas, rather than tearing down the person contributing them.
It's the difference between "This code isn't any good, here are the problems
with it, I'm confident you can do better on your next attempt" (last part
optional but usually beneficial when it comes to growing your contributor
community) and "This code is terrible, how dare you befoul my presence with
it, begone from my sight, worm!".

The latter response may be a funny joke if done in private between close
friends, but when it's done in public, in front of a large number of
onlookers who don't know either the sender or the recipient personally, it
sets an astoundingly bad example as to what a mutually beneficial
collaborative peer relationship should look like.

And if you don't have the self-discipline needed to cope with the changing
context of our online interactions in the open source community? Well,
perhaps you don't yet have the temperament needed to be an open source leader
on an internet that is no longer the sole preserve of those of us that are
more interested in computers than we are in people. Most of the technical and
business press have yet to figure out that they can actually do a bit of
investigative journalism to see how well vendor rhetoric aligns with upstream
open source engineering activity (frequency of publication is still a far
more important performance metric for most journalists than questioning the
spin served up in corporate press releases), so the number of folks peering
into the open source development fishbowl is only going to grow over time.

It isn't that hard to learn the necessary self-control, though. It's mostly
just a matter of taking the time to read each email or code review comment,
look for the parts that are about the contributor rather than the code or the
design, and remove them before hitting send. And if that means there's
nothing left? Then what you were about to send was pure noise, adding nothing
useful to the conversation, and hence best left unsent. Doing anything less
than this as a community leader is pure self-indulgence, putting your own
unwillingness to consider the consequences of your communications ahead of
the long term interests of your project. We're only talking about software
here, after all - lives aren't on the line when we're deciding how to respond
to a particular contribution, so we can afford to take a few moments to
review the messages we're about to send and consider how they're likely to
be perceived, both by the recipient, and by everyone else observing the
exchange.

With any personal abuse removed, you can be as ruthless about critiquing the
code and design as you like. Learning not to take critiques of your work
personally is a necessary skill to acquire if your ambition is to become a
high profile open source developer - the compromises often necessary in the
real world of software design and development mean that you will end up
shipping things that can legitimately be described as terrible, and you're
going to have to learn to be able to say "Yes, I know it's terrible, for
reasons X, Y, and Z, and I decided to publish it anyway. If you don't like
it, don't use it.". (I highly recommend giving talks about these areas you
know are terrible - they're fun to prepare, fun to give, and it's quite
entertaining seeing the horrified reactions when people realise I'm not
kidding when I say all software is terrible and computers don't actually
work, they just fake it fairly well through an ongoing series of horrible
hacks built atop other horrible hacks. I'm not surprised the Internet
breaks sometimes - given the decades of accumulated legacy hardware and
software we're building on and working around, it's thoroughly astonishing
that anything technology related ever works at all)

But no matter how harsh your technical critiques get, never forget that
there's at least one other human on the far end of that code review or
email thread. Even if you don't personally care about them, do you really
think it's a good idea to go through life providing large numbers of people
with public evidence of why you are a thoroughly unpleasant person to be
forced to deal with? As a project leader, do you really think you're going
to attract the best and brightest people, who are often free to spend their
time and energy however they like, if you set up a sign saying "You must be
willing to tolerate extensive personal abuse in order to participate here"?

What can we do about it?

First, and foremost, for those of us that are paid open source community
leaders, we can recognise that understanding and motivating our contributors
and potential contributors in order to grow our communities is part of our
job. If we don't like that, if we'd prefer to be able to "just focus on the
code", to the degree where we're not willing to learn how to moderate our
own behaviour in accordance with our level of responsibility, then we need
to figure out how to reorganise things such that there's someone with better
people management and communication skills in a position to act as a buffer
between us and our respective communities.

If we instead decide we need to better educate ourselves, then there are
plenty of resources available for us to do so. For folks just beginning to
explore questions of systemic bias and defaulting to exclusivity,
gender-based bias is a good one to start with, by perusing resources like the
Feminism 101 section on
the Geek Feminism wiki, or (if we have the opportunity) attending an
Ada Initiative
Ally Skills workshop.

And if we do acknowledge the importance of this work, then we can use our
influence to help it continue, whether that's by sponsoring educational
workshops, supporting financial assistance programs, ensuring suitable codes
of conduct are in place for our events and online communities, supporting
programs like the GNOME Outreach Program for Women, or organisations like
the Ada Initiative, and so on, and so forth.

For those of us that aren't community leaders, then one of the most
effective things we can do is vote with our feet: at last count, there are
over a million open source projects in existence, many of them are run in
such a way that participating in them is almost always a sheer pleasure,
and if no existing community grabs your interest, you always have the option
of starting your own.

Personal enjoyment is only one reason for participating in open source though,
and professional obligations or personal needs may bring us into contact with
project leaders and contributors that currently consider personal abuse to be
an acceptable way of interacting with their peers in a collaborative context.
If leaving isn't a viable option, then what can we do?

Firstly, the options I suggest above for community leaders are actually good
options for any participants in the open source community that view the
overall growth and success of the free and open source software ethos as
being more important than any one individual's personal pride or reluctance to
educate themselves about issues that don't affect them personally.

Secondly, we can hold our leaders to account. When community leaders give
presentations at community events, especially when presenting on community
management topics, feel free to ask the following questions (or variations
on these themes):

Are we as community leaders aware of the impact current and historical
structural inequalities have on the demographics of our community?

What have we done recently as individuals to improve our understanding of
these issues and their consequences?

What have we done recently as community leaders to attempt to counter the
systemic biases adversely affecting the demographics of our communities?

These are questions that open source community leaders should be able to
answer. When we can't, I guess the silver lining is that it means we have
plenty of scope to get better at what we do. For members of vulnerable
groups, an inability for leaders to answer these questions is also a
strong sign as to which communities may not yet be able to provide safe
spaces for you to participate without experiencing harassment over your
identity rather than being critiqued solely based on the quality of your
work.

If you ask these questions, you will get people complaining about bringing
politics into a technical environment. The folks complaining are simply wrong,
as the single most important factor driving the quality of our technology is
the quality of our thinking. Assuming we have attained meritocracy (aka "the
most effective collaborative environment possible") is sheer foolishness,
when a wide array of systemic biases remain in place that work to reduce the
depth, breadth, and hence quality, of our collective thinking.

Over the weekend, Asher Wolf
alerted me (and
many others in the open source and cryptographic communities) to the
Australian Defence Trade Controls Act 2012, and the current public
consultation taking place around a bill proposing amendments to that act.

Being heavily involved in improving the security of open source
infrastructure like the Python Package Index
and the
Python 2 reference interpreter,
working at a multinational open source vendor, and having an extensive
background in working under the constraints of the US International Traffic
in Arms regulations, Asher's concern caught my attention, since bad
legislation in this area can have significant chilling effects on legitimate
research and development activities.

As a result, I've escalated this legislation for review by the legal teams
at various open source companies and organisations, with a view to making
formal submissions to the
public consultation process
that is open until January 30th (ready for bills to be submitted for
consideration to federal parliament on February 23rd).

However, I was also able to attend the first public consultation session
held at the University of Queensland on January 19, so these are my
impressions based primarily on that sessions and my own experiences dealing
with ITAR. I'm not a lawyer and I haven't actually read the legislation,
so I'm not going to pick up on any drafting errors, but I can at least speak
to the intent of the folks involved in moving this process forward.

What not to worry about

To folks encountering this kind of legislation for the first time, the
sheer scope of the
Defence and Strategic Goods List
can seem absolutely terrifying. This was very clear to me from some of the
questions various academics in the room were asking.

On this particular point, I can only say: "Don't panic". This isn't a
unique-to-Australia list, it's backed by a treaty called the
Wassenaar Arrangement - the DSGL represents
part of the implementation of that arrangement into Australian law.

When the laws implementing that arrangement are well drafted, everyone outside
the military industrial complex (and certain easily weaponised areas of
scientific research) can pretty much ignore them, while everyone
inside the military industrial complex (and the affected areas of research)
pays very close attention to them because we like not being in jail (and
because gunrunning is bad, and bioterrorism is worse, mmm'kay?).

A heavily regulated military supply chain is already scary enough, we really
don't want to see the likely consequences of an unregulated one. (And if
you're tempted to make a snarky comment about the latter already being the
case, no, it really isn't. While folks can sometimes use overclassification
to avoid regulations they're supposed to be following, that still introduces
significant friction and inefficiencies into whatever they're doing. It's not
as good as people actually respecting the laws of the countries they're
supposedly defending, including genuinely meeting the requirement for
civilian authority over the military, but it's still a hell of a lot better
than nothing).

Getting back on topic, the US ITAR and crypto export control laws are
currently considered the most strict implementation of the Wassenaar
Arrangement amongst the participating nations (going beyond the requirements
of the treaty in several areas), so if you see plenty of US nationals
participating in an activity without being fined and going to jail, you can
be fairly confident that it isn't actually a controlled activity under the
DSGL (or, even if it is, permits for that specific activity will be fairly
easy to get, and the most likely consequence of not realising you need a
permit for something you're doing will be someone from your government
getting in touch to point out that you should apply for one).

There are certainly some very questionable aspects of this list (with the
perennial "favourite" being the fact the Wassenaar Arrangement does, in fact,
attempt to regulate the global trade in mathematics, which is just as stupid
and problematic as it sounds), but it's a known quantity, and one we're pretty
sure we can continue to live with (at least for the time being).

What to worry about

The real problem here is that the regulations included in the 2012 Act are
not well drafted, and the legislated 2 year transition period from May 2013
through to May 2015 prior to the enforcement provisions kicking in is about
to run out.

The biggest problem with the 2012 act is that in trying to keep things simple
(essentially, "if its on the DSGL, you need a permit"), it ended up becoming
extraordinarily draconian, requiring a permit for things that don't require
an export license even under ITAR.

For the general public, the most significant shift in the 2015 amendment bill
is the fact that several cases around open publication of information related
to dual-use technologies shift to being allowed by default, and only in
exceptional cases would a permit be required (and in those cases, the onus
would be on the government to inform the covered individuals of that
requirement).

The amendments also include a variety of additional exemptions for little
things like making it legal for Australian's own police and security agencies
to collaborate with their international counterparts. (Snarky comment
opportunity #2: in certain areas, making such collaboration illegal seems
like a potentially attractive idea...)

That 2 year pilot was included in the original legislation as a safety
mechanism, the feedback from the associated steering group has been
extensive, and if things had gone according to plan, the relevant amendments
to the bill would have been passed last year in the spring sitting of federal
parliament, leaving DECO with at least 6 months to educate affected
organisations and individuals, and start issuing the now necessary permits
before the enforcement provisions became active in May. Unfortunately, we
currently have a federal government that views pushing a particular
ideological agenda as being more important than actually doing their job,
so we're now faced with the prospect of regulations that industry doesn't
want, academia doesn't want, the Australian public service don't want, and
the Australian military don't want, coming into effect anyway.

Isn't politics fun?

What DECO are (trying) to do about it

The group tasked with untangling this particular legislative Charlie Foxtrot
is the Australian Defence Export Control Office (DECO). Their proposal for
addressing the situation hinges on two bills that they plan to put before
the next sitting of federal parliament:

an amendment bill for the Act itself, which fixes it to be a conventional
implementation of the Wassenaar Arrangement, in line with existing
implementations in other Wassenaar nations (why we didn't just do that in
the first place is beyond me, but at least DECO are trying to fix the
mistake now)

a second bill to delay the enactment of the enforcement provisions for
a further six months to provide sufficient time for DECO to properly
educate affected parties and start issuing permits

As far as I am aware, the second bill is needed primarily due to the
consideration of the first bill slipping by six months, since we're now
looking at the prospect of only having 4 weeks for DECO to start issuing
permits before the enforcement provisions come into effect. Nobody involved
thinks that's a good idea.

If both of those bills pass promptly, then the only cause for concern is
whether or not there are any remaining devils in the details of the
legislation itself. Member of the general public aren't going to be able to
pick those up - despite the surface similarities, legalese isn't English, and
reading it without interpreting it in the context of relevant case law can be
a good way to get yourself into trouble. Summary translations from legalese
to English by a competent lawyer are a much safer bet, although still not
perfect. (For the programmers reading this: I personally find it useful
to think of legalese as source code that runs on the language interpreter of
a given nation's legal system, while the English translations are the code
comments and documentation that anyone should be able to read if they
understand the general concepts involved).

If at least the second bill passes, then we have another 6 months to work on
a better resolution to the problem.

If neither bill passes, then DECO end up in a bad situation where they'll
be required by law to implement and enforce regulations that they're
convinced are a bad idea. They actually have everything in place to do that
if they have to, but they don't want this outcome, and neither does anyone
else.

What industry and academia can do about it

While it's very short notice, the main thing industry and academia can do
is to file formal submissions with DECO as described in their overview of
the public consultation process.

There are three main things to be addressed on that front:

ensuring federal parliament are aware of the importance of amending the
Defence Trade Controls Act 2012 to eliminate the more draconian provisions

ensuring federal parliament are aware of the infeasibility of putting this
into effect on the original timeline and the need for a significant delay
in the introduction of the enforcement provisions

ensuring DECO are alerted to any remaining areas of concern in the
specific drafting of the amended legislation (although I'd advise skipping
this one if you're not a lawyer yourself - it's the functional equivalent
of a lawyer with no training as a programmer proposing patches to the Linux
kernel)

We were apparently asleep at the wheel when DTCA went through in 2012, so
we owe a lot of thanks to whoever it was that advocated for and achieved
the inclusion of the two year transition and consultation period in the
original bill. Now we need to help ensure that our currently somewhat
dysfunctional federal parliament doesn't keep us from receiving the benefit
of that foresight.

What's definitely not going to happen

This consultation process is not the place to rail against the details of
the Wassenaar Arrangement or Australia's participation in it. You won't
achieve anything except to waste the time of folks that currently have a
really serious problem to fix, and a very limited window in which to fix it.

Yes, Wassenaar has some serious problems, especially around its handling
of cryptography and cryptographic research, but we have a fairly settled
approach to handling that at this point in history. The critical concern in
this current case is to help DECO ensure that the associated Australian
regulations can be readily handled through the mechanisms that have already
been put in place to handle existing Wassenaar enforcement regimes in other
countries. With the way the 2012 Act was drafted, that's almost certainly
currently not the case, but the proposed 2015 amendments should fix it
(assuming the amendments actually have the effects that DECO has indicated
they're intended to).