But as incredible as the language is, we as a community continue to have a deep-seated diversity problem, and we need to take more steps to address it. Just as importantly, Apple needs to take some steps to address it, because they are just as much part of the problem.
Swift was released as an open source project over two years ago, and Apple said this about Swift’s core team:
At project launch, the team is composed of Apple employees due to Swift’s origin within Apple. Over time, exceptional community members from a much more diverse background will be appointed based on their record of community involvement and contributions.
Back then the Swift core team was made up of Chris Lattner, Doug Gregor, Ted Kremenek, Joe Pamer, Joe Groff, John McCall, and Dave Abrahams – all men, all working for Apple. Things have changed a little today, but not in any meaningful way: Lattner now works at Google, Joe Pamer has left, and Ben Cohen has joined.
I have nothing against middle-aged white guys – I am a middle-aged white guy – but I don’t think anyone could argue that this constitutes “a much more diverse background.”
But the problem goes beyond just Apple. In the last few weeks I’ve been exchanging emails with the organizer of a well-known conference because I’m concerned that the speaker selection doesn’t reflect the diversity in our community. Their response has been positive: they acknowledge there’s a problem, and are keen to find ways to do better.
I spoke to Ellen Shapiro – a hugely respected iOS developer and conference speaker – and asked her for some ways conferences can do better:
“I would point to UIKonf’s CFP process as a good example of totally blind and 360|iDev’s as partially blind. UIKonf has no idea who’s speaking from the CFP until they’re selected – it’s a great way to get some new voices in. 360 does blind judging for the first round then does take other stuff (experience, diversity, etc) into account in other rounds.”
Both of these do a pretty good job of finding diverse speakers. UIKonf’s approach is to have everyone submit one talk anonymously, judges then reject any they don’t like, and the public have the final say on which talks they want to see.
However, this is still a reactive approach – it relies on folks having the confidence to put themselves forward, having the ability to craft good proposals, and even being interested in the conference in the first place.
Ellen has some great advice here:
“Don’t focus on just getting more women, but more diversity of all kinds. Get first time speakers and help them with their talks. Be a launching pad for new speakers instead of the same voices like… well, me. The biggest thing is it can’t be done as part of the Call For Papers (CFP) process alone, there must be other ongoing efforts. Conferences hate hearing that because it means more work but it’s the only thing I’ve seen be super effective.”
So, we’re faced with a two-pronged problem: at the top Apple continues to drive Swift forward with a core team that has barely changed since the project launch, and at the grassroots our conferences often continue to be dominated by mostly white, mostly male speakers.
We can do better, and we need to do better. If you’re running a conference, Ellen has already given some great advice above – if you do nothing more than anonymize your CFP process then you’ve taken a big step forward, but if you’re also able to go beyond that and actually have an ongoing program to help diversify your speaker intake then you’ll see real gains.
As for Swift’s core team, I hope we’ll see the original promise of “exceptional community members from a much more diverse background” come true in the near future. We have an incredibly diverse community for them to draw on, not least:
And those are just some suggestions for starters. It’s International Women’s Day in just two days, and it would be nice to celebrate with a Swift Core Team that didn’t all look like me.
We can do better – Apple can do better – but it’s something everyone needs to work at.
PS: For March, if you are under-represented in tech and work with iOS/Swift I’ll have a Skype call with you to talk about anything you want. Want career advice? Code tips? Something else? I’m here to help – just send an email to firstname.lastname@example.org.
SPONSOR Tired of wasting time debugging your Swift app? Instabug’s SDK is here to help you minimize your debugging time by providing you with complete device details, network logs, and reproduction steps with every bug report. All data is attached automatically. It only takes a line of code to setup. Get started for free.
Paul Hudson is the creator of Hacking with Swift, the most comprehensive series of Swift books in the world. He's also the editor of Swift Developer News, the maintainer of the Swift Knowledge Base, and Mario Kart world champion. OK, so that last part isn't true. If you're curious you can learn more here.