11, 13 Hi everyone. Thanks for coming out. I’m super thrilled to be here, this now makes 4 PyCons, in 4 countries, on 3 continents in the last year for me. So that’s really cool, thanks for having me. A huge round of applause for the organizers, this has been a phenomenal conference thus far.
almost to the day, August 15th, 2010, I gave a talk at an education conference titled “Open Source and Education”. I talked to a group of educators and researchers about the practices we were using in open source. Specifically about the overlaps between techniques from pedagogy, from teaching, and practices we’ve organically developed in the open source community.
And a few months ago I get approached about speaking here, and I start thinking “what are the things I know about that people might want to hear”. And I realized through conversations I’ve had, a lot of people actively working in open source don’t really know these things. So I figured it was something worth sharing.
13 Before I really dive in, I figure you might want to know how I know stuff about open source. . I write a lot of it; I’m a core dev for Django, CPython, PyPy; my day job is now working on open source, from libcloud to openstack, and many other projects at Rackspace. I help shepherd it: I serve as a director of the Python Software Foundation, and before that of the Django Software Foundation. And of course, I use it all the time, so I’m approaching this from a lot of angles. Anything I say about psychology, pedagogy, or sociology is something I read in a paper somewhere. I’m not an expert in those fields, please call me out if I get something wrong. The conference organizers seem to be messing with my head a little, they put me between two individuals who are actually qualified to speak on this stuff.
Before we dive into the “why”, we should spend a few minutes discussing the “what” of open source, because open source describes a pretty wide range of behaviors
11, 13 So the way I see it there are about three types of software that match the definition of open source. The first is code dumps, here’s some software, look it’s open! This is basically the same as closed source development, except there’s some code you and I can look at at the end. The next is public development, this is something like Android, theres a public VCS repo, you can see people working on it, but the progress isn’t driven by a process open to the public. And finally there’s open development, this is what we’re going to talk about today, and this is probably what most of the OSS projects you know are: this is Django, this is Python, this is OpenStack, this is Linux, etc.
Bug reports • IRC / mailing lists Open development practices Sunday, August 11, 13 These are some of the practices exhibited by open development projects, certainly not an exhaustive list.
August 11, 13 Many many many developer hours. Often from either our free time, or our employers time. Why do we volunteer our time like this, why do our employers let us spend *their* time on this stuff? Those are the questions I want to try to answer for us. Because intuitively it’s bonkers, who lets their employees give away their code, what person goes home and does the same type of stuff as they do at the job.
begin unpacking this, first I wanted to take a look at what people believe themselves. So I put out a survey, 3 questions, “Do you contribute to Open Source?”, “Why do you contribute to Open Source?”, “Why don't you contribute to open source any more (or as much as you'd like to)?”. 150 responses. ~50% contribute regularly, 28% have contributed in the past, 15% have not contributed before, 5% other. Decent sample size, population is biased, it’s all people within one or two degrees of me socially, and I have weird social circles. So those are the opinions I collected.
13 There were some really varied answers to “Why do you contribute to open source?”, I’ve tried to coalesce ones that were the same, and I’m only going to talk about some of the more common answers.
13 This was, by a decent margin, the most common answer. A lot of people feel their professional lives have benefited hugely from their usage of open source, so they want to pay it forward, so to speak.
your own itch” is another strong motivator, people who use software hit bugs or need more features and then they want to fix them and share that with the world. If you hang around the development lists for Django or Python you’ve probably heart someone say something like, “Well, I don’t have this need, but maybe if you do and you write the code, it’s worth having”, so people’s intuition has some merit, we write the software we need.
bunched these together, but they’re actually pretty different. People who wrote about developing skills tended to talk about working with talented programmers, getting really good code reviews, or learning new code bases. In contract, career advancement was about the professional visibility that comes from contributing to open source. That’s not to say it’s a bad thing, just a different thing.
powers nearly everything, to one degree or another, a lot of people want to keep that up. This is in some senses a variation on “To give back”, it also encompass things like “I love knowing that tons of companies use my work”.
paid to write open source all day. I’m really lucky to be one of them. There are companies literally paying people to give away software. That’s awesome.
This is a question I get a lot from friends and family members. Why are you writing all this software and giving it away, couldn’t you sell it and make some money? I’d characterize this as the naive economists point of view. Yeah, I could sell some of the stuff I write (some of it really has no commercial value of course), but I value a lot of other things as well. The master economist knows that there are things besides money which incentivize.
we’ve talked a lot about what people believe about what they do. Now I want to dive into some of what the academic literature says. This isn’t specifically research on open source contribution, but more general research on what motivates us to work and to learn.
want to obtain a skill. We all want to be able to say “I’m good at this”, we want to understand in greater depth our craft. Open source rewards and encourages this. We get to work with experts who’ll review our code, we get to take time with no deadlines to perfect our patch, and to try to learn something new. I want to learn more about unit testing, I can find a project that needs some tests and contribute. Why do the “experts” want to take their time to code review? Because they care about the health of their projects, and new contributors are the lifeblood of that, by helping someone level up their skills you’re grooming a future maintainer, and you never know who’s going to outpace you and make the project better than you imagined.
be in control of what they do. And no one tells you what to do in open source. Some days I work on a compiler, some days I do cryptography (PS: this is scary), some days I work on an ORM or a web framework. I direct myself to projects I’m interested in, to things I care about. I also get to choose how I work on these things, in terms of the aesthetics of code, architectural decisions. I work with others because I value their knowledge and opinions, but I ultimately have direction over how I work on them.
part of something. To work with and learn from others. To help bring new people into the fold. To see a little piece of software grow up and change the world.
for working on Django. The biggest reward I can give another developer, is to make them also a core developer, to enable them to contribute more. There’s a ton of research on this subject, simply put, for intellectual, creative tasks, rewards don’t motivate you. In fact they de-motivate you, they replace your intrinsic motivation with extrinsic. Instead of contributing because you want to help the community, you contribute for the reward, and when the reward goes away, so does your motivation. The funny bit, and there’s research that shows this: even when you give people these facts, they still want to believe that rewards work.
work on something. We sat down to write documentation about security policy for Django, and this is something important right, particularly we wanted to give people a hard timeline, if you report a security issue, we WILL respond within 48 hours. How do you make that guarantee when it’s everyone’s free time? What can you say, oh do this or we’ll fire you from this thing you donate in your free time? Ethical issues aside, when you’re coerced you perform worse, and you care about the quality of your work less. We can make statements like “response in 48 hours” precisely because everyone participates voluntarily, we understand this is important so we make it a priority for ourselves, and that gives way better results.
contributors, we don’t try to give you a score, no “You get a B+ on Django this month”. It turns out there are 3 primary effects of evaluating in this way, a) You become motivated by the evaluation, the grade becomes a reward, b) you care less about the underlying work, and c) you seek the easiest task that gets you good evaluations, you don’t try to challenge yourself, because that might get you a worse grade at contributing to Django. In contrast, open source gives feedback. Here’s how you can improve this patch, here’s how you’re doing a great job helping out on the mailing lists, if you focus on this aspect of your code reviews, you’ll be more effective.
but what about companies? Surely they could make more money, and have fewer competitors, why give away the secret sauce? But instead companies are some of the biggest drivers of open source, the majority of the work on the Linux kernel is by people paid to work on it, for example.
to give back to. They recognize that when they choose an open source technology, it’s not a static thing, that they need to help promote and grow the community of developers, and that they can help by improving it.
13 An open community can improve software beyond what an individual company can do. OpenStack is a really fantastic example of this, the project moves at a lightning pace, they do hundreds of CI runs a day (often hundreds an hour!), with many companies and individuals contributing.
be a part of a community too. Specifically it means things like, you can hire people with existing skill sets, you don’t have to train someone on your custom framework, it’s the hot new thing that everyone knows already.
key to recognizing why corporate involvement in open source is that competition and cooperation are not mutually exclusive, and neither is a static mode of behavior. There are things that it’s important we cooperate on, and there are things where competition helps produce better results.
far, but I want to share some of the challenges as well, like Jacob said yesterday, challenge is just another word for opportunity, it’s places we can get better. These are challenges that individuals face in contributing to open source, and challenges that communities face.
big one for people who want to contribute, or want to contribute more than they do. When their work comes out of their free time, it’s pretty strictly bounded by how much real life interferes. Money clashes a bit with what I said about rewards right, does paying people to work on open source change it’s nature? This is a longer conversation, and I don’t have the research to fully back this up, but my experience says there’s a fundamental difference between paying someone for their freetime, and allowing them to make it their full time.
huge challenge for open source communities. I think in the Python community in particular has done great work here over the past few years. But there’s always room for improvement. We can do an even better job, being welcoming to people of diverse backgrounds, different levels of ability, and different perspectives. Unfortunately one of the most common reasons people identified for not participating in open source was because of jerky maintainers. We need to strive to be a community where that isn’t ok.
not to contribute is feeling like you don’t have the skills or the knowledge or the background needed. I’m not totally sure how we solve this, but we need to, because everyone can help. I have over 120 repositories on github. It’s no exaggeration to say half of those are forks I created to fix a single typo. And wearing my maintainer hat I have to say, I love when someone sends me a typo fix patch, every little bit helps.
Philo Farnsworth? He invented television, in Provo, Utah, and then did the first TV broadcast from San Francisco. He was a visionary, and he died broke. But I really want to tell you about his brother in law, Cliff Gardner. Cliff saw Philo’s drawings, and recognized that this was something that was going to be important, so he said, “I don’t really understand the science behind all of this, but it looks like you’re going to need glass tubes, how would it be if I learned to blow glass and made them for you?”, Philo was inventing the cathode receptor, and glass tubes weren’t really a thing you could buy, “This looks important, and I want to help” is what Cliff said. That’s open source.
I continue the metaphor, I want to point out that the majority of that is taken from a TV show written by Aaron Sorkin called Sports Night, and I highly recommend you all watch. Aaron, if you read or hear this, please don’t sue me.
source is glass tubes. Almost none of us will start the next linux kernel, but we can all learn to contribute. The majority of open source is not creating the next great new project, it’s contributing a missing paragraph to the docs, it’s writing a great bug report with a test case, it’s adding the small missing feature. We contribute because we’ve built our hobbies or our careers on this stuff, and we know it’s important, because it’s fun, because it helps us learn, because it lets us be a part of something. And we can all learn to blow glass tubes.
any merit at all to this whacky open source thing, I’d like to encourage you to join the sprints. There’ll be people from a lot of projects, who want nothing more than to help you get started contributing.
Before we finish, I want to apologize quickly, original versions of this talk came with citations and more statistics to back up some of the studies I mentioned. Unfortunately those are all in a pad of paper back at my apartment in San Francisco, whoops. If there’s any interest at all, reach out to me, on twitter or email, and I’ll get those online. Thank you all for coming and listening, thanks you all for your past contributions to open source, thank you for your future contributions. We’ve got some time for questions now.
alex
tomoya0x00
nkforwork
nhayato
tnagao7
corocn
philipschwarz
beomi
wenas
ikumatadokoro
tkikuc
yahonda
yanagii
lauravandoore
phodgson
62gerente
bermonpainter
cromwellryan
geoffreycrofte
notwaldorf
caitiem20
bkeepers
pauljervisheath
destraynor
wjessup
![Thank you. [email protected] / @alex_gaynor https://speakerdeck.com/alex Sunday, August 11, 13](https://files.speakerdeck.com/presentations/28bde250e4cd01300287264be62e937e/slide_40.jpg){kind=link}