The Selfish Side of Open Source

coding open source
Posted on: 2015-01-16

Photo by Drew Geraets, via Unsplash.com - https://unsplash.com/drewgeraets

“Why would programmers work for free?” That’s the reaction some people have to open source software. What is this, some kind of communist utopia?

I’ve created several open source projects and contributed to many more. And I do have some unselfish reasons.

  • I get so much from open source. My favorite language, libraries, text editor, and source control tool are all open source and free. So are all of the command line tools I use, and the operating system I deploy on. It’s nice to give something back.
  • I think it fits the nature of software. Humans can’t all live in the same house, but we could all use the same piece of code. Why duplicate effort rewriting it a million times? Open source means software can be reused, not rewritten.
  • I enjoy helping people.

You might say that open source software is like a tree with good fruit. If you like the fruit, water the tree.

But the truth is, there are selfish reasons why we work on open source, too. Both developers and companies benefit from releasing open source software.

How developers benefit

Answer your own questions

Once, I was using Formtastic and had trouble figuring out how to use custom inputs. I dug around in the source code, and eventually, I figured it out.

What next? I could record my discovery somewhere, but I’d probably lose it.

Instead, I contributed to the project’s documentation. Now I know exactly how to find that info: with a search engine.

In the same spirit, that’s part of why I post on this blog and on StackOverflow. Sometimes I’ll ask and answer a question on StackOverflow that I’ve already figured out, just so that I can find it later by searching. I’m glad it helps others, but it helps me, too.

Offload your patches

My first open source code contribution was to Nokogiri, an XML-parsing tool in Ruby. I was using it wrong, but there was no error message, so it took me a while to figure out.

Once I did, what could I do? I could try to remember what I did wrong. But I was sure I’d forget.

I could improve the code to raise a helpful error message, and keep the improvement to myself. But then I’d face a terrible choice: either be locked to my patched version forever, or forever maintain a fork, merging in any other changes. Because nobody would know about my patch, they wouldn’t know or care if they broke it.

What I did instead was contribute it back, with a test case. My patch is now part of the main project.

Which is great for me. Where do I get the improved version? That’s easy: from Rubygems. Who ensures that the existing code doesn’t break my patch? The project maintainers do.

After the initial work of contributing, I get none of the upkeep and all of the benefits. Sweet!

Hang on to your work

In my career, I’ve built some neat things.

  • An office map that links to employee profiles, editable by drag-and-drop
  • A database query scheduler that forbids schema changes during peak traffic hours
  • A financial transaction system with complex rules
  • A monitor for Git repos and servers, ensuring that no code is deployed unless its been checked in (to prevent shenanigans)
  • A fast currency-conversion service
  • A hypermedia client

But all of those things were closed source. I did the work and got paid, but the company owns the code. Leaving the job means never seeing that code again.

On the other hand, I also built a Rails authorization gem and an ORM query builder that work exactly the way I want. I worked on those at a previous employer, but I can still use that code, and I can still refer back to it. Why? Because anyone can. It’s open source.

These days, if I’m solving a problem that’s not business-specific, and I think I’ll need that solution again someday, I consider making it open source. It’s a gift to my future self.

Now, please notice that all the benefits I’ve mentioned so far came to me even if nobody else cares about my contributions. But I also have to mention…

Reputation

It’s nice to have a good reputation. And while I’m not one of the better-known programmers in the Ruby community, my open source work has helped. I met some people at a conference once who knew me as “the Authority guy”. That felt nice.

It’s also good for finding work. For example, in my last job search, one potential employer skipped the technical interview because their developers were already using my code. They knew they liked my work before we ever talked. My reputation made it easier to find a job, which made it easier to find a job I really like.

Yes, there can be problems with using open source to screen candidates. It doesn’t prove that I’m a good team member - I could be lazy, for example. But two important traits for a developer are technical skill and the ability to communicate well. And my open source work shows both: I’ve communicated my ideas to my peers, and they’ve liked my code enough to use it.

(I should point out that maintaining a project is both more work and more reward than contributing to one. The reputation is nice, it’s not all roses - search for “open source guilt” to see some of the downsides.)

Company

OK, we’ve covered reasons for developers to do open source. But what about companies? What’s in it for them?

More productive developers

In some ways, what’s good for developers is good for their employers. If your devs are using open source code, you want it to work well for your purposes, and to have good documentation for the features you need. Your developers can ensure that if you let them contribute.

Higher-quality code

Open source can help you “battle-harden” your code. Outsiders may notice bugs before your developers do, and may even fix them. Open sourcing some code is like planting a seed; getting good patches is like harvesting the fruit.

Developer pride plays a role here, too. When your developers hand in proprietary code, they’re saying “this is good enough to do what you requested.” But when they release open source, they’re saying “I’m willing to publicly sign my name to this and attach it to my reputation.” Which one do you think they’ll work harder to perfect?

Higher-quality documentation

Open source also encourages documentation. At a previous job, I tried to make my code clear, and wrote comments when necessary. But it’s tempting to be lazy; after all, if a fellow developer didn’t understand my code, they could just ask me.

On the other hand, I documented everything about my open source code. I had to, because it was for strangers, and the documentation was all they’d have in deciding whether and how to use it.

I’ve since changed jobs, and new developers have joined my old company. I’m not around to answer their questions, and if I’ve done my work well, they don’t need me to be. But they definitely have plenty of documentation for my gems, not to mention a place to ask questions where I, or other users, can answer them.

Attract developers and clients

I’ve said that open source is good for a developer’s career. You may think, “why do I want my developers polishing their resumes on my time? They’ll just find a better job and leave.” But that’s only one side of the equation. Developers know that open source is good for us, so we’re more likely to take a job if we know the employer will let us contribute.

And with enough effort, your company’s open source work can become part of its reputation, too. Thoughtbot has said publicly that their open source work brings them both developers and clients, and I believe it. I’d love to work for them, and I know about them solely through their open source code and free content.

It’s even possible to build a company around open source, as Leah Silber has explained.

We’re all selfish

I’ve used the word “selfish” to describe these motivations, but perhaps that’s a little strong. Everyone has to think about themselves and their loved ones first. Caring for our own interests is often a way of caring for those we love.

But it’s beautiful when doing what’s good for ourselves leads to benefit for others. It’s like the “invisible hand” in economics: the baker makes good bread for a good price because that’s how she attracts customers. Her reasons are selfish, but her customers benefit.

Open source is the same, but with different currency. Instead of bread for cash, it’s code for code, or code for respect. Often, those things bring money as a side effect.

So, be a little selfish. Scratch your own itch, and hang on to your work. Do work you’re proud of, and be known for it.

We’ll all thank you for it.