How We Worked on Eliminating Bias in Our Hiring Process: A Small Organization's Story
byon June 20, 2019
We recently hired our newest employee at Conservancy, a Technical Bookkeeper. Adding one more employee to our small staff is a significant change for our organization and we wanted to conduct both an efficient and as unbiased as possible hiring process. This can be a challenge for small organizations and there must be agreement around this goal as well as a willingness to stick to a slightly more formal process. Everyone here at Conservancy was committed to crafting a process designed to remove as much bias as possible from the equation, so here's what we did.
Posting the Job
This is the posting that we shared with our networks. We specifically never implied that we expected applicants of any particular age or gender. We weren't looking for any particular type of educational history, so there's no mention of schooling here. In fact, we proactively stated that we were open to applicants from all different backgrounds. Since it's an unusual role, we were willing to train applicants who had a non-complete mix of the skills the job would use and we said so. Finally, we strongly encouraged folks from under-represented groups to apply -- not as a short-hand CYA, "EOE!" but in a specific way that we hope conveyed our belief that diversity is critical for our organization and our mission. We were so happy to be overwhelmed by strong applications from over thirty people who are passionate about software freedom.
First off, we asked all of the applicants the same questions, which we fully formulated in advance. It's important that you don't compare apples to oranges and keep the interview about the skills and qualities needed for the role you are currently interviewing for. For this first stage, no one on staff screened anyone they already knew well. We made an effort to stay on topic so we wouldn't be tempted to bias for "chattiness" or "culture fit." We also did not look at candidates on social media, in order to keep appearance, race and age from informing our first impression.
After the screen, we let all candidates know one way or the other whether we would be advancing their candidacy. Timely communication and a reasonably quick-paced process was part of our overall goal. While we didn't move as fast as we would have liked over the whole process due to our small size and large workload, we made sure to notify our candidates as soon as we knew whether they were advancing or not. A slow process increases the chance that your best applicants will have taken another job by the time you get back to them and there's absolutely no need to string people along that you don't intend to hire. The screen reduced the field to 12 candidates we were really excited to move forward with.
Since this opening was for a technical role, we needed to know about people's technical skills. We wanted to make sure we understood where our candidates were technically, without making assumptions about the experiences on their resumes. To do this, we organized a do-at-home exercise with a time constraint. There was no whiteboard and no audience while the work was being done by each applicant on their own machine. We told applicants they could look things up, because that is what people do when they are on the job. (They know there's a tool or library that could help them, but they don't quite remember the name of it or what the exact argument is that will help in a particular situation.) We allowed applicants to choose a time slot over a two week period to take the test, so they could schedule the exercise around current work or care-giving responsibilities.
Bias is unconscious. While we try to be good, unbiased people, Conservancy staff has all been subtly and not so subtly exposed to racist, sexist and ageist ideas and defaults throughout our lives. The staff members who sent the technical exercise to the applicants gave each person a two letter code name. We wanted the other two staff members who rated each applicant's answers to be able to do so without any information about age, gender, race or national origin interfering with their assessments. This process allowed us to identify our four top candidates, based entirely on their anonymous work product.
For the final candidates, we wanted to schedule a longer interview. Again, we asked all of the final applicants the same questions. We tried not to let the conversation drift into personal anecdotes or irrelevant topics. We also worked to make sure the applicants had an accurate picture of the day to day tasks they would be doing and asked questions about how they would handle that work and the obstacles that are likely to come up during a typical work week in that role. We contacted the candidates' references and also asked all of them the same set of questions. We interviewed some amazing people for the role. The final interviews set up a very tough decision for us and the process strengthened our shared desire to continue expanding Conservancy's staff.
At the end of the day, we were only hiring for one opening and so we chose the best person for our current role. In the future, we might have multiple or complimentary openings that we'd have to jostle, but not today. We're very happy with the result -- welcome aboard Rosanne!
Conservancy News Round-up
byon May 28, 2019
May is for code releases! Check out these videos, blog posts from member projects, code releases and upcoming events.
Recent Videos and Podcasts
Deb's talk on Free Software/Utopia is up, on the Free software Foundation's MediaGoblin server.
Deb was also the guest of honor on Libre Lounge, Episode 19: Community Development with Deb Nicholson. Thanks to Chris and Serge for their dedication to free software and to Conservancy's work!
On Free as in Freedom, Karen and Bradley discuss two additional permissions that can be used to “backport” the GPLv3 Termination provisions to GPLv2 — the Kernel Enforcement Statement Additional Permission, and the Red Hat Cooperation Commitment.
Our Member Projects Have Been Busy
This summer's Outreachy interns were announced. "Congratulations to the 43 interns accepted to the Outreachy May 2019 to August 2019 round!"
phpMyAdmin -- along with several other Conservancy projects -- are excited about participating in Outreachy this round.
MicroBlocks presented at ROBOLOT, an educational robotics conference held in Catalan. The video of their panel is about 75% Catalan and 25% English, so feel to skip around or brush up on your Catalan.
The Godot team attended GDC, aka the "Game Developers Conference" in San Francisco reported on their improved name recognition at this year's event.
The folks at Reproducible Builds, shared" that security and software supply chain attacks were in the news and that this was a busy month for their distro work.
Some recent code releases:
- Kallithea 0.4.1 released
- Mercurial 5.0 released
- QEMU 4.0 adds micro:bit emulation support
- Samba 4.10.4 available for download
- SWIG-4.0.0 released
- Wine 4.0.1 released
Etherpad merged in a big chunk of code to improve recovery from brief server outages. "The resulting code is 15% smaller than before, and is also much easier to comprehend."
What's coming up?
Catch up with staff:
Karen keynotes sambaXP on June 5th at 10:15 local time in Göttingen, Germany.
Bradley will be at the Ninth Annual RacketCon in Salt Lake City, Utah, where he will give a talk titled, "Conservancy and Racket: What We Can Do Together!"
Many of our projects have events coming up:
First talks are announced for Selenium's upcoming London conference, tickets are available now.
North Bay Python has announced their dates for this year's event, November 2 & 3, 2019. Talk submissions will open soon!
Chasing Quick Fixes To Sustainability
byon May 23, 2019
Various companies and trade associations have now launched their own tweak on answers to the question of “FOSS sustainability”. We commented in March on Linux Foundation's Community Bridge, and Bradley's talk at SCALE 2019 focused on this issue (video). Assuring that developers are funded to continue to maintain and improve FOSS is the focus of many organizations in our community, including charities like ourselves, the Free Software Foundation, the GNOME Foundation, Software in the Public Interest, and others.
Today, another for-profit company, GitHub, announced their sponsors program. We're glad that GitHub is taking seriously the issue of assuring that those doing the work in FOSS are financially supported. We hope that GitHub will ultimately facilitate charities as payees, so that Conservancy membership projects can benefit. We realize the program is in beta, but our overarching concern remains that the fundamental approach of this new program fails to address any of the major issues that have already been identified in FOSS sustainability.
Conservancy has paid hundreds of thousands of dollars to fund FOSS developers over the course of our existence. We find that managing the community goverance, carefully negotating with communities about who will be paid, how paid workers interact with the unpaid volunteers, and otherwise managing and assuring that donor dollars are well spent to advance the project are the great challenges of FOSS sustainability. We realize that newcomers to this discussion (like GitHub and their parent company, Microsoft) may not be aware of these complex problems. We also have sympathy for their current approach: when Conservancy started, we too thought that merely putting up a donation button and routing payments was the primary and central activity to assure FOSS sustainability. We quickly discovered that those tasks are prerequisite, but alone are not sufficient to succeed.
Just as important is how the infrastructure is implemented. GitHub is a proprietary software platform for FOSS development, and their sponsors program implements more proprietary software on top of that proprietary platform. FOSS developers should have FOSS that helps them fund their work. Choosing FOSS instead of proprietary software is not always easy initially. Conservancy promotes free-as-in-freedom solutions like our Houdini project and other initiatives throughout our community. We are somewhat alarmed at the advent of so many entrants into the FOSS sustainability space that offer proprietary software and/or proprietary network services as a proposed solution. We hope that GitHub and others who have entered this space recently will collaborate with the existing community of charities who are already working on this problem and remain in search of long-term sustainable, FOSS-friendly solutions.
Choosing a GPLv3-termination Backport to GPLv2 (KESAP vs. GPLCC)
byon May 11, 2019
About four years ago, Conservancy (in collaboration with the Free Software Foundation) published the Principles of Community-Oriented GPL enforcement. Our goal was to conduct our enforcement ethically and respectfully, treating today's violators as tomorrow's contributors. Accordingly, the Principles advocate a holistic approach to GPL enforcement that truly seeks to gain GPL compliance to advance software freedom. We were so happy about the way the Principles assisted the Netfilter team and we were excited that there was substantial interest in codifying these long standing ad-hoc Principles into a widely adopted and published consensus.
Ideas in FOSS also have a way of taking on a life of their own; we share our ideas in the hopes that others will build on them. We have been pleasantly surprised that the last Principle, “Community-oriented compliance processes should extend the benefit of GPLv3-like termination, even for GPLv2-only works”, received so much interest.
This interest led to two independent initiatives to
“backport” the GPLv3 termination provisions — by way of
an additional permission — to GPLv2-only-licensed works. Additional
permissions to GPLv2 have been used for various purposes since the early
1990s (such as for
exception). Additional permissions grant more leeway — relaxing some requirement of the default license — in an effort to reach some policy goal for the project. In this case, the additional permission softens the strict terms of the GPLv2 termination provisions, which state that
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this
License. That means permissions under GPLv2 are instantly and permanently lost on even
easily-correctable violations and require reinstatement of permissions by
copyright holders. In contrast, the GPLv3 version gives downstream
violators short time periods to comply and receive automatic
reinstatement of permissions,
via the following
If you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
This improved policy can indeed be “backported” to GPLv2 via an additional permission.
Two efforts over the last year and a half have “implemented” these backports. The first released was the solution now used by the Linux community, which states:
Notwithstanding the termination provisions of the GPL-2.0, we agree that it is in the best interests of our development community to adopt the following provisions of GPL-3.0 as additional permissions under our license with respect to any non-defensive assertion of rights under the license, However: [Quotes GPLv3 termination provisions as above]
We call this sub-document the Kernel Enforcement Statement Additional Permission (“KESAP”), as it is published as part of a larger document named “Kernel Enforcement Statement”. (The rest of that document does not contain legally binding terms.)The second effort, inspired by this KESAP, was released later by Red Hat, which they call the GPL Cooperation Commitment (often abbreviated GPL-CC or GPLCC), but which we will call here “RHCC” to avoid any confusion with FSF initiatives around the GPL and license drafting, and because to most people in licensing, CC refers to “Creative Commons”. The RHCC is available on github.
Adopting One of the Additional Permissions
Conservancy finds both documents intriguing and worthy of additional study and consideration. Moreover, Conservancy has decided that we will adopt one of these GPLv3-termination-backport provisions for copyrights we hold, and advocate adoption for other copyrights held by contributors for our member projects. While we don't demand this of anyone (and won't make use of such an additional permission mandatory for our GPLv2'd projects), we make a strong recommendation for use of a GPLv3-termination-backporting additional permission.
We have for months carefully considered which of the two options is the best to adopt. This was a difficult decision, since the two are similar and both have some problematic aspects. While we applaud both the Linux community and Red Hat for promulgating these useful additional permissions, on balance we prefer KESAP, and so we are adopting and endorsing KESAP. Below we discuss our reasons for this choice between the two for those who wish more detail. Anyone interested can also listen to episode 0x67 of Free as in Freedom where we discuss these issues in detail.
Length and Complexity
KESAP is about half as long as RHCC. When you remove the direct quote in both documents that come from GPLv3's text itself (which obviously must be included in both), the RHCC adds 1,180 words and KESAP adds only 323.
The RHCC is also more complex. It adds additional defined terms, including redefining “We”, which is already a term used in GPLv2's preamble to refer to the FSF. It adds an irrevocability clause, which is not harmful, but it is unnecessary since unilaterally granted copyright permissions are generally irrevocable anyway. Furthermore, given that the word “irrevocable” doesn't appear in GPLv2, adding a redundant irrevocable clause could easily confuse license readers into thinking that GPLv2 itself is otherwise revocable even while the additional permission is not.
Aggressive Defensive Termination Violates Principles
Our biggest concern with both KESAP and RHCC is that they only apply in “non-defensive” situations. This allows copyright holders to fail to provide 30 days for violators to repair violations when those violators are already aggressors in some other form of litigation.
While we are somewhat sympathetic to those who might seek to use GPL enforcement to retaliate against other bad actions, we believe that even potential bad actors deserve the benefit of the doubt and the meager 30 days to repair a violation before facing aggressive enforcement tactics. Furthermore, defensive actions that bring the GPL into court as part of business dispute otherwise unrelated to free software are also the most likely litigation to generate bad legal precedent regarding the GPL. (Indeed, many of the lawsuits that have already been brought over the GPL are in this category. While so far these have settled out of court, there's no reason to expect that to always happen in the future.) We are disappointed that both sets of drafters feel that copyright holders should hold back this permission in those cases. As the Principles state, we continue to discourage any legal action (defensive or otherwise) against a copyright holder who otherwise succeeds in producing a compliant GPL'd source release within 30 days of violation notice. We ask Red Hat and the Linux community to also make this same cure commitment universally, perhaps in an updated version of these additional permissions.
We do note that RHCC is slightly better on this point, since it does narrow non-defensive via a defined term, but it does not narrow it enough to make a real difference, while also adding additional complexity. Moreover, the text specifically mentions legal proceedings and claims, which draws attention to the very activities that make nervous copyleft software adopters skittish.
Additional Permissions Should Not Codify Assent Mechanisms
RHCC has its own orthogonal assent mechanism, based on the presence of a file in the repository. This assent mechanism, while it seems similar to a traditional inbound=outbound regime, is actually novel and untested. The mechanism attempts to gain assent based on a specific date of inclusion of the RHCC file in a repository. Contributors, however, do not necessarily receive any notice of the addition of that file, and therefore their assent is unclear.
For example, imagine a pull request from two levels downstream that waits for merge for months. The modern DVCS-based software development process allows developers to work indefinitely on a forked copy of the repository and there is no way to know that the contributor had a copy of the repository that pre-dated the addition of the file, and they may not have a copy of the RHCC in their repository. When all is merged, it will appear that their commit postdated the addition of the RHCC, but the contributor may be unaware that the exception is added.
Furthermore, many projects already have licensing assent systems that are
likely incompatible with one that is baked into the RHCC. Indeed, Linux
itself has decided that they cannot make KESAP part of the DCO assent,
since too many Linux developers already believe
means assent merely to GPLv2-only-compatible licensing. The RHCC, when
added to a existing project, cannot be adapted to fit a DCO process without
modification of the DCO. Since
Signed-Off-By tags rarely
assent specifically to a version of the Project's DCO, RHCC is
incompatible with a DCO-assent-based inbound=outbound assent system.
By contrast, the KESAP is flexible on assent. The entire KES, which includes the actual additional permission that is the KESAP, asks contributors to affirmatively assent with a patch that adds their own name to the file — explicitly indicating assent. Extracted from the KES, the KESAP text can be combined easily with virtually any assent mechanism in use in FOSS today. RHCC simply cannot.
Adding KESAP to your project
Linux is the gold standard of frictionless legal assent that is well-accepted by both individual hobbyists and contributors and corporate contributions and users alike. Recommending the Linux solution to this particular GPLv3-termination backport is simply the best way to quickly promulgate these additional permissions to GPLv2'd projects. We'll be working over the coming months to encourage, and hopefully assist, Conservancy's LGPLv2'd and GPLv2'd (or-later) member projects to implement KESAP. We will also relicense all Conservancy's own GPLv2 (or-later) copyrights to include the KESAP.