by Yevgeniy (Jim) Brikman5/26/2016
I’m going to ask you two questions.
Pause for a minute and think deeply about your answers before reading further: – What are the best software companies in the world? – Who are the best software engineers in the world?
Did you come up with a list of names? If so, how many names are on that list? Three? Five? Maybe ten, at most? There are thousands of software companies and software engineers doing incredible things, but when I ask you for the best, I bet only a select few names pop into your head. Why these names and not others?
It’s because these companies and developers not only do great work, but also spend time telling you that they do great work. I’d bet that for every company and programmer on your list, you’ve read their writing (e.g., blogs, papers, books), seen their presentations (e.g., talks, conferences, meetups), and/or used their code (e.g., open source).
For example, if your list of programmers included Linus Torvalds, it’s probably because you’re familiar with Linux or Git, both of which he developed as free, open source projects. If you had Dennis Ritchie on your list, it’s probably because he was one of the people responsible for creating Unix and C, and the open standards, open source libraries, and books about them. Or perhaps your list of companies included Google, which is known for regularly publishing open research papers, making the Google Talks series available online for everyone to see, and open sourcing massive projects like Android, Chrome, Angular, and Go. Other major software companies, including Facebook, Twitter, LinkedIn, and these days, even traditionally-closed-source Microsoft, are also regularly releasing millions of lines of open source code for everyone to use. There are even companies built entirely around open source that give away almost everything they do, such as Mozilla and Red Hat.
The question is, why? Why do so many software companies and developers give away so much of their work? Why would they invest thousands of hours and millions of dollars into a project and then release it for free to everyone, even their competitors? Is it really all about altruism?
While altruism plays a role, it’s only one part of the explanation. In this blog post, I’ll dive into the other key reasons why the best companies and developers share almost everything they do, discuss some of the common objections to sharing, and by the end, I hope to convince you and your company to start sharing too.
Reasons to share
Roughly two out of every three software companies contributes to open source. On GitHub alone, there are over 14 million developers contributing to more than 35 million projects. And while these numbers are already impressive, it’s important to remember that open source is growing at an exponential rate, so these numbers are going to get much, much bigger.
Open source, blog posts, and talks aren’t really about charity. Sure, many developers genuinely want to give back to the community, but that by itself doesn’t explain the ubiquity of sharing in the software industry. The real reasons behind sharing come down to the fact that sharing gives back more than you put in, in the form of mastery, quality, labor, marketing, and ownership.
The best way to learn is to teach. That’s because to explain a topic to someone else, you have to understand it more deeply yourself. Every time I’ve prepared a talk, written a blog post, or contributed to an open source project, I’ve walked away knowing more than I knew going in.
As a company, encouraging your employees to write, talk, and open source is one of the cheapest and most effective training programs you can do. And as an individual, taking the time to share your knowledge is one of the easiest and most effective ways to level-up. In fact, the hallmark of a “senior” engineer is that they make everyone around them better, and the only way to do that is to teach.
When is your home cleanest? My guess is that you do the most cleaning just before guests arrive. The same is true of anything that you share with others. One of the unexpected benefits of open sourcing your code is that the mere act of preparing the code for open source often leads to higher-quality code because you know that “guests” will be looking at it. You’ll probably take the time to clean up the code, add tests, write documentation, and generally make the project more presentable to the rest of the world. The same is true if you write a blog post or give a talk about your work. The act of sharing a project makes that project better.
Sharing your work can lead to better quality in another way too: feedback. All feedback, on your writing or talks, including the negative feedback, is a chance for learning and improving. Sometimes you find out that you didn’t do a good job of communicating something, or that you didn’t cover an important aspect of the topic, or that there is an entirely different perspective on an issue you hadn’t considered. With open source code, the feedback aspect is even more powerful, as it is inherently a form of peer-review. Because of this, it has become the norm, even the standard, to develop complicated and critical software systems, such as security libraries, operating systems, and programming languages as open source, and there is evidence that open source projects have higher quality, on average, than proprietary ones.
“Given enough eyeballs, all bugs are shallow. I dub this: Linus’s Law.” –Eric S. Raymond, The Cathedral and the Bazaar
Every time someone uses your open source code and files a bug, they are doing QA, for free. Every time someone submits a patch to your open source project, they are developing software for you, for free. Every time someone writes a blog post about your open source project, they are writing documentation for you, for free. And if that blog post is a scathing negative review, well, even then they are giving you a design review, for free.
Sharing your work with others allows the entire software community to contribute, which makes it possible for projects to become larger and higher quality than anything you could do on your own, especially if you work at a small startup. And even if you work at a large company, you’ll find lots of amazing developers who you can’t hire—maybe because you don’t have the budget for it, or those developers already have jobs, or they live in a different part of the world—but if you create a great open source project, then those developers may contribute to it, for free. For example, more than 3,000 people have contributed code to the open source Ruby on Rails web framework, not to mention the tens of thousands more who have used the framework, reported bugs, written blog posts, and created plugins. If your company is thinking of writing its own proprietary web framework, how many people do you think you’ll be able to dedicate to it?
If you’re a developer, the best way to make yourself look good in front of an employer is to share your work. Think of it like inbound marketing for your career. Instead of blindly spamming your message to the world (e.g., through sending job applications) and hoping someone takes notice, you attract the employer by sharing content they find valuable. If you can get developers at that company to read your blog posts, watch your talks, and use your open source projects, they will begin to see you as an expert and are more likely to want to hire you. The work you share becomes a permanent part of your résumé. In fact, it’s even better: as jQuery creator John Resig said on Twitter, “When it comes to hiring, I’ll take a Github commit log over a résumé any day.”
If you’re an employer, it works the other way, too. The best way to make yourself look good in front of developers is to share your work. If a developer has been using your company’s open source code for years, they are more likely to want to join your company and continue using that code. An open source project is one of the most effective ways to attract tech talent, and a far better job advertisement than a traditional job posting.
As a developer, if I put thousands of hours of effort into a project, I tend to get attached to it. It’s my baby. If it’s a proprietary project, leaving the company is a bit like getting a divorce and losing custody of the kids. It’s painful, and after you’ve done it a few times, it’s hard to be as passionate about investing in something that isn’t really yours.
However, if you get to give talks about the work, publish blog posts and papers, and best of all, open source your project, then it’s yours for life. It becomes a permanent part of your toolbelt, something you can take with you anywhere you go, something you can show to others, and something you’ll be proud to work on.
In other words, open source projects are simply more fun and more satisfying to work on. And in an era where everyone is competing for tech talent, making a job more fun can be a huge advantage.
“It may well turn out that one of the most important effects of open source’s success will be to teach us that play is the most economically efficient mode of creative work.” — Eric S. Raymond, The Cathedral and the Bazaar
Reasons not to share
Even after reading all the above, I typically still run into three common objections to sharing work:
• “I don’t have time.” • “No one will look at my work.” • “Someone will steal my work.”
Let’s go through them one at a time.
I don’t have time
The most common reason for not taking the time to write a blog, give a talk, or open source code is, “I’m too busy.” Every time that thought pops into your head, try to remember this: busy is a decision. You don’t find the time to do things, you make the time, just as you would make the time to stay late at work to meet an important deadline, go to a doctor’s appointment, attend a Game of Thrones watching party, or anything else you think is important. And sharing, as it turns out, is extremely important if you want to have a successful career.
In professional sports, grueling workouts and intense training sessions are a standard part of the job. Similarly, professional musicians, dancers, and chess players spend hours honing their craft every day. And yet with most office jobs, once you graduate from college and complete a ramp-up program at your new company, dedicated time for learning and training comes to an end. In other words, if you walk around the typical office, almost everyone you see is stuck at a plateau.
It doesn’t have to be that way. Every night, at 11 p.m., I sit down for 20-40 minutes to create, learn, and share. Depending on my mood, I may watch a video, read a book, write a blog post (such as this one), or work on an open source project. I’ve found that this simple routine where I regularly investing a small amount of time in learning—and just as importantly, sharing what I’ve learned—has completely transformed my career.
Make learning and sharing a regular part of your schedule. Find a time that works for you—perhaps just before work, during lunch, or before bed—and commit to it for 20-40 minutes every day. This might not seem like much time, but think of it like compound interest: a small amount invested now grows into something huge over time.
No one will look at my work
It doesn’t matter if no one ever reads your blog or uses your open source project. Writing, speaking, and open source, first and foremost, are learning tools for you. As William Zinsser said in On Writing Well, writing is just thinking on paper. The primary goal of a blog is to improve your own thinking, so it’s worth doing even if no one reads it. Similarly, putting together a presentation and articulating your ideas to others will help clarify your own thoughts. And as I discussed earlier, the work you do to open source your code makes that code better.
That said, if you practice your writing, speaking, and coding, your audience may grow. It starts with your friends and colleagues, but slowly, especially if you share your work on sites like Twitter, Facebook, LinkedIn, Reddit, and Hacker News, strangers will find your work, share it, and offer feedback. Moreover, on the Internet, where no one sees you in person, your identity is writing, speaking, and open source. Whatever turns up when I Google your name is who you are. In other words, in the modern world, you are what you share.
And if you’re worried that no one will be interested in what you have to say, just remember that everyone is at a different stage in their learning:
“You’d be amazed at how many things you take for granted as ‘common knowledge’ are actually brand new to other smart people. There’s simply too much to know in this world, and we’re all continually learning. (I hope). Often I’ll get discouraged because I feel like I’m writing about things that have already been discussed into the ground by others. The thing I have to remember is that there’s a ‘right time’ to learn something, and it’s different for everyone.
…No matter where you are in your education, some people will be interested in hearing your struggles. This is an important thing to keep in mind when you’re blogging. Each person in your audience is on a different clock, and all of them are ahead of you in some ways and behind you in others. The point of blogging is that we all agree to share where we’re at and not poke fun at people who seem to be behind us, because they may know other things that we won’t truly understand for years, if ever.”
— Steve Yegge, You Should Write Blogs
Someone will steal my work.
Most people do not have the interest, time, knowledge, passion, or skills to steal your work. As Howard H. Aiken said, “If your ideas are any good, you’ll have to ram them down people’s throats.” Moreover, even if someone does “steal” ideas from your writing or starts using your open source project, in most cases, that’s a good thing, as their feedback and contributions can make your work better than you could alone.
The only time it would matter if someone steals your work is if it allows a competitor to overtake you. This is only possible if you give away your primary differentiator. For example, for a company like Google, their primary differentiator would be their search architecture—that is, the search algorithms and the massive distributed systems that index the web and respond to queries. This is their “secret sauce,” and not something they are likely to ever share in its entirety.
But for just about everything else, Google benefits more from sharing it than from keeping it secret, which is why they have open sourced more than [20 million lines of code in over 900 projects] not directly related to search. They’ve released papers around their search architecture too (e.g. [PageRank], [MapReduce], and the [Google File System]), as merely hearing an idea is not enough to steal it. In fact, if your idea is simple enough that someone could steal it and beat you just from reading a paper or hearing a talk, then that idea probably wasn’t defensible enough to begin with. Compare “I have an idea for a social network” to “I’ve developed a way to launch objects into space” (from [Startup Engineering].) Execution is what matters, and that’s a lot harder to steal.
The culture of sharing
In just about all aspects of life, doing great work is not enough to be successful. You also have to make sure other people know that you’re doing great work. I find that this is an especially hard lesson to learn for programmers, who tend to be introverted and cynical of anything that looks like marketing or self-promotion. But the good news is that sharing your work is a virtuous cycle that can dramatically improve both the work itself and your abilities. And once you realize that sharing the work isn’t an extra step, but an integral part of the work itself—just as writing documentation and tests is an integral part of writing code—you’ll find more success in many aspects of your life, including finding jobs, earning promotions, attracting customers, and hiring coworkers.
The culture of sharing is one of the reasons the software industry and Silicon Valley have been so successful. Compared to something like Wall Street, where secrecy is king, the tech industry is remarkably open. And when we all share, we all win. Or, to paraphrase Isaac Newton, in a culture of sharing, we can all see further by standing on the shoulders of giants.
This is why I give talks, open source code, and write blog posts (including this one): by sharing what I know, I learn new things myself, and can see a little bit farther. I’d love to hear your thoughts!
Yevgeniy (Jim) Brikman is the author of [Hello, Startup] and the founder of [Gruntwork], a company that specializes in helping new startups get off the ground. Previously, he spent more than a decade at LinkedIn, TripAdvisor, Cisco Systems, and Thomson Financial. He has a BS and Masters in Computer Science from Cornell University.