Creating a Commons
Hi, I’m Bess Sadler, and I work at Stanford University Library. I build open source software for libraries, and it’s pretty important to me. This is not my first code4lib, I’ve been around for awhile.
We lost a member of our community this year. Aaron Swartz spoke at code4lib in Portland in 2008. His work on Open Library was inspiring to many of us, including me. He was a library hacker in the very best sense, and he brought a sense of ethics to his work that affected me deeply. I am glad to have known him, and I am grateful for his contributions.
In addition to his work with bibliographic data, Aaron also helped to design the creative commons licenses.
I love the creative commons licenses. In case you haven’t encountered them before, let me explain that they say the same thing in three vocabularies: Machine readable, human readable, and lawyer readable.
I’d like to suggest that successful community developed software projects, and technology communities like code4lib, should adopt the same strategy.
Machine readable means cool uris, and unit test coverage, continuous integration, and semantic markup.
It means building software that’s easy to integrate, and is able to accept code contributions without breaking. I won’t spend much time on this because it has already been well covered at this conference, and in books like Practices of an Agile Developer and Producing Open Source Software. I will just say that shared engineering practices become more and more important the larger and more distributed your development team becomes, and it is an investment that’s worth making.
And lawyer readable, well, we’re not lawyers, so I don’t want to spend a whole lot of time on legal contracts, except to say, yes, you really do need to figure out your governance and legal structure if you want to collaborate across institutions for very long. And it’s a very good idea to get anyone who is contributing code to your project to sign a contributor license agreement. It goes a long way toward establishing a clear legal standing for any code that is produced.
Being lawyer readable can make your life a lot easier, and can make a big difference in whether your software project attracts new adopters and committers. In fact, it might determine whether their employment contract allows them to participate at all.
Again, this is covered in the books I just recommended, and the apache software foundation also maintains an excellent guide to getting your open source software project on firm legal footing. Again, this is an investment in your project and your community that is worth making. I too love under the radar software that we develop and share informally. I don’t want to lose the spirit of informal collaboration that code4lib does so well. But we must recognize that we live in a larger context, one where major lawsuits have happened because of unclear code provenance. Be smart and protect yourself.
Machine readable, lawyer readable, these are important. But what I really want to talk about today is being human readable.
When we build software, what are we building? Software code, certainly, but we are also building ways of doing things, a group of people who know how to work together, and the traditions they create. In other words, a culture. In other words, a commons.
How many people here went over to the fedora4lib house this week? Fedora4lib is a team of software engineers from several institutions, who arrived in Chicago early, rented a house together, and have been collaboratively creating the next version of fedora. They had a couple of open house events this week, which were really fun.
When I got over there Chris Beer had just baked cookies. This is definitely my idea of developer happiness. I talked to the developers, and the feedback I heard was that not only had they been productive and produced something that all of these institutions can benefit from, they felt closer as a team, they communicated better.
Hydra, in addition to being a digital repository solution, is a community. In fact, increasingly, this seems like our primary identity. What we are finding is that the ability to collaborate on common solutions is more important than any single project. This gives us resiliency, and room to experiment. I think having a community makes us feel safe enough to take risks, and sharing work frees up our time to innovate. By trusting each other, and cultivating in each other a willingness to experiment, we get to try cool experiments like fedora4lib. And I think we’ve hit on something worth doing again.
This intentional focus on hydra as a community has been a successful strategy. You might have noticed from the talks this year, quite a few institutions have been joining the hydra community, and it seems to be working out well for them. In fact, we realized recently that the limiting factor on our growth was our ability to hire and train people to build and run these repositories.
That’s one of the reasons I’ve been spending some time this year teaching for RailsBridge in San Francisco. I am thinking about how to teach digital library concepts to people who are new to programming, or new to libraries, or both. Partly this is to help meet the hiring and training needs of hydra institutions, but it’s also because I believe that building and maintaining library software is vitally important work and it’s too big a job to leave to a small group of people. We are creating the future of libraries here. I feel like the stakes are pretty high. I want the solutions we develop to be inclusive, and I am deeply worried about the fact that only 2% of open source software developers are women. I want to do something about that, and teaching seems like a way I can make a contribution.
But when I think about what it is I’d really like to teach people who are new to coding for libraries, what I come up with isn’t about technology so much as it is about adopting a problem solving mindset, something I am starting to think of as “hacker epistemology.” Epistemology, if you’re not familiar with the term, refers to the question of how we decide what’s true, how we construct knowledge. For example, someone might have an epistemology of received knowledge. That person would decide what was true based on what an authority figure told them was true. Here in code4lib, many of us have more of what I think of as a hacker epistemology, this magic combination of collaborative knowledge building, combined with a disregard for the mental traps of conventional thinking. We like to take things apart and see how they work. Sometimes we listen to what authority figures tell us, but we easily discard received knowledge if we gather evidence that contradicts it. I think it’s this attitude that has made code4lib so successful. We value rough consensus and working code. The truth is what works.
I was very sorry to miss code4lib last year. I hear that Dan Chudnov delivered an outstanding keynote. I am sorry I missed it, but happy that I got to hear a little about it last night. If I understand Dan’s message, he was saying that it’s important for us to grow code4lib to accommodate all of the people who want to join us and contribute to our work. I couldn’t agree more. This year, we have more people here than ever before. We have taken major steps forward in making code4lib more open and welcoming for newcomers. Now I want to take a few more steps in the direction of building inclusive community.
I love code4lib, and I make extensive use of it, so it seems only natural to me to want to improve it. Step one in hacking a system is trying to understand the system, and looking for places where it might be possible to make a change. One way I hacked code4lib this year was by requesting that we adopt a code of conduct.
Having a code of conduct is becoming a recognized best practice in the open source community, and a proven way to attract a more diverse audience for conferences and communities of all kinds. I am pleased to say that we did adopt a code of conduct, and we join great organizations like the Linux Foundation and the O’Reilly conferences, in taking this step. As of January 9, the django software foundation will only sponsor events with a published code of conduct, and more and more open source projects are following suit. After code4lib adopted our code of conduct, CurateCamp adopted a similar statement. I find all of this very encouraging.
Andâ€¦ I get it, not everyone thinks it’s necessary, just like not everyone wants to sign a contributor license agreement. But having a readable consensus statement about our values, and a positive affirmation that this is a safe space, really does improve the quality of our commons.
I didn’t ask for a code of conduct because of anything egregious that had happened in code4lib, but because it’s a good idea organizationally, and because I wanted us to make an explicit statement about inclusiveness. Unfortunately, we as a community do not get to start from an assumption that this is a safe and welcoming space. Sexual harassment and assault have been rampant problems in the technology world, including the world of open source software. This has been true for a long time, but thanks to courageous community members who are willing to speak publicly, who make themselves vulnerable to further attacks by refusing to remain silent, these incidents are being discussed and we as a community have an opportunity to fix this critical bug in our culture.
If we don’t define our own parameters, we are accepting the default. And the default is terrible. We can do much better than that, and we have to let people know we want to try.
Another way I hacked code4lib this year was by submitting more than one talk. For those of you new to our speaker selection process, people can submit as many talk proposals as they want, but they can only give one. We periodically discuss changing this policy, but I’d like to request that we keep it. And, I’d like to invite people to use this policy the way I do. It is important to me to have women on this stage. I want diversity of all kinds, for example I would also like to see more public libraries represented in code4lib, but given that librarianship is a majority female profession, but the tech side is majority male, I am particularly concerned with hearing from more women at this conference.
— We are all impostors.
And here, this is my final hack for this year:
Who here has ever felt like there are some astonishingly smart people in code4lib? Who has ever felt afraid they couldn’t keep up? Raise your hand.
I feel like that a lot. I think all of us do. And if we just acknowledge that truth, we go a long way toward disarming that intimidation factor.
I was talking with a friend of mine this week about these issues. He is someone who I think of as an ultimate code4lib insider. He gives talks, teaches workshops, and writes amazing software. And yet he confessed to me this week that he often feels, especially at code4lib, that he is surrounded by people who are smarter than he is, and he can sometimes feel like he’s faking it. He told me that the way he deals with that is to bolster himself, to put on his game face, to go into the world armored with masculinity and emotional invulnerability. “Do you think,” he asked me, “it might make a difference to our ability to be inclusive, if I stopped doing that? If I just admitted that I don’t know what I’m doing sometimes?” I had to try really hard not to reach out and hug him. “Yes,” I said, “I think that would make a huge difference. We should all do that.”
This makes me think of what researcher Brene Brown has to say about vulnerability.
Vulnerability is not weakness. Vulnerability is the courage to show up and allow ourselves to be seen. To try, even when we have no guarantee of success.
When we make our code public, when we allow others to find our weak spots and help us strengthen them, that is vulnerability that leads to strength. And when we acknowledge our own emotional vulnerability, the fact that many of us feel lost and overwhelmed, by technology, by work, by life, then we allow others to acknowledge those things too, and we create a context where we can support each other.
So those are my attempts at hacking on this community to make it fit my needs better. But clearly, this task is too big for me to accomplish alone. I’d like us to set up a system for accepting bug reports on our commons. The code of conduct we just adopted is our current working document for how we have decided to do that. The process can, undoubtedly, be improved further, and I encourage us all to think about how to do that.
My request of you, of us, is that we put on our hacker mindset when we file and receive these bug reports. For example, this week I received a bug report that the original title of my talk, “How to be an effective evangelist for your open source project,” was a little alienating to some here for reasons that, I admit, were invisible to me until a friend explained that, as someone who identifies as Jewish, he often feels made invisible by Christian metaphors. He didn’t like to bring it up, but he trusted me enough to let me know that that word bothered him. Because we were having a conversation where we were explicitly trying to be honest with each other without hurting each other, instead of getting defensive I was able to stay present, stay vulnerable, and accept his bug report. And I changed it. And now my presentation is better and I feel closer to my friend. This is a good system.
This community is so special to me. I joined the code4lib irc channel when I was in library school, back in 2003, before there was a conference. This community has been a source of strength to me, a place where I have made wonderful friends and developed my own skills far beyond what I once thought I was capable of. I am so happy to see the ways that we have grown, and eager to see what we’ll do next.
Thank you, code4lib, for another great year.