Why the Best Companies and Developers Give Away Almost Everything They Do

Why the Best Companies and Developers Give Away Almost Everything They Do

Illustrative image of people standing in arrow shape representing development and teamwork


I’m going to ask you two questions.

Pause for a minute and think deeply about your an­swers be­fore read­ing fur­ther:

  • What are the best soft­ware com­pa­nies in the world?
  • Who are the best soft­ware en­gi­neers 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 thou­sands of soft­ware com­pa­nies and soft­ware en­gi­neers doing in­cred­i­ble things, but when I ask you for the best, I bet only a se­lect few names pop into your head. Why these names and not oth­ers?

It’s be­cause these com­pa­nies and de­vel­op­ers not only do great work, but also spend time telling you that they do great work. I’d bet that for every com­pany and pro­gram­mer on your list, you’ve read their writ­ing (e.g., blogs, pa­pers, books), seen their pre­sen­ta­tions (e.g., talks, con­fer­ences, mee­tups), and/or used their code (e.g., open source).

For ex­am­ple, if your list of pro­gram­mers in­cluded Linus Tor­valds, it’s prob­a­bly be­cause you’re fa­mil­iar with Linux or Git, both of which he de­vel­oped as free, open source pro­jects. If you had Den­nis Ritchie on your list, it’s prob­a­bly be­cause he was one of the peo­ple re­spon­si­ble for cre­at­ing Unix and C, and the open stan­dards, open source li­braries, and books about them. Or per­haps your list of com­pa­nies in­cluded Google, which is known for reg­u­larly pub­lish­ing open re­search pa­pers, mak­ing the Google Talks se­ries avail­able on­line for every­one to see, and open sourc­ing mas­sive pro­jects like An­droid, Chrome, An­gu­lar, and Go. Other major soft­ware com­pa­nies, in­clud­ing Face­book, Twit­ter, LinkedIn, and these days, even tra­di­tion­ally-closed-source Mi­crosoft, are also reg­u­larly re­leas­ing mil­lions of lines of open source code for every­one to use. There are even com­pa­nies built en­tirely around open source that give away al­most every­thing they do, such as Mozilla and Red Hat.

The ques­tion is, why? Why do so many soft­ware com­pa­nies and de­vel­op­ers give away so much of their work? Why would they in­vest thou­sands of hours and mil­lions of dol­lars into a pro­ject and then re­lease it for free to every­one, even their com­peti­tors? Is it re­ally all about al­tru­ism?

While al­tru­ism plays a role, it’s only one part of the ex­pla­na­tion. In this blog post, I’ll dive into the other key rea­sons why the best com­pa­nies and de­vel­op­ers share al­most every­thing they do, dis­cuss some of the com­mon ob­jec­tions to shar­ing, and by the end, I hope to con­vince you and your com­pany to start shar­ing too.

Reasons to share

Roughly two out of every three soft­ware com­pa­nies con­tributes to open source. On GitHub alone, there are over 14 mil­lion de­vel­op­ers con­tribut­ing to more than 35 mil­lion pro­jects. And while these num­bers are al­ready im­pres­sive, it’s im­por­tant to re­mem­ber that open source is grow­ing at an ex­po­nen­tial rate, so these num­bers are going to get much, much big­ger.

Open source, blog posts, and talks aren’t re­ally about char­ity. Sure, many de­vel­op­ers gen­uinely want to give back to the com­mu­nity, but that by it­self doesn’t ex­plain the ubiq­uity of shar­ing in the soft­ware in­dus­try. The real rea­sons be­hind shar­ing come down to the fact that shar­ing gives back more than you put in, in the form of mas­tery, qual­ity, labor, mar­ket­ing, and own­er­ship.


The best way to learn is to teach. That’s be­cause to ex­plain a topic to some­one else, you have to un­der­stand it more deeply your­self. Every time I’ve pre­pared a talk, writ­ten a blog post, or con­tributed to an open source pro­ject, I’ve walked away know­ing more than I knew going in.

As a com­pany, en­cour­ag­ing your em­ploy­ees to write, talk, and open source is one of the cheap­est and most ef­fec­tive train­ing pro­grams you can do. And as an in­di­vid­ual, tak­ing the time to share your knowl­edge is one of the eas­i­est and most ef­fec­tive ways to level-up. In fact, the hall­mark of a “se­nior” en­gi­neer is that they make every­one around them bet­ter, and the only way to do that is to teach.



When is your home clean­est? My guess is that you do the most clean­ing just be­fore guests ar­rive. The same is true of any­thing that you share with oth­ers. One of the un­ex­pected ben­e­fits of open sourc­ing your code is that the mere act of prepar­ing the code for open source often leads to higher-qual­ity code be­cause you know that “guests” will be look­ing at it. You’ll prob­a­bly take the time to clean up the code, add tests, write doc­u­men­ta­tion, and gen­er­ally make the pro­ject more pre­sentable 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 shar­ing a pro­ject makes that pro­ject bet­ter.

Shar­ing your work can lead to bet­ter qual­ity in an­other way too: feed­back. All feed­back, on your writ­ing or talks, in­clud­ing the neg­a­tive feed­back, is a chance for learn­ing and im­prov­ing. Some­times you find out that you didn’t do a good job of com­mu­ni­cat­ing some­thing, or that you didn’t cover an im­por­tant as­pect of the topic, or that there is an en­tirely dif­fer­ent per­spec­tive on an issue you hadn’t con­sid­ered. With open source code, the feed­back as­pect is even more pow­er­ful, as it is in­her­ently a form of peer-re­view. Be­cause of this, it has be­come the norm, even the stan­dard, to de­velop com­pli­cated and crit­i­cal soft­ware sys­tems, such as se­cu­rity li­braries, op­er­at­ing sys­tems, and pro­gram­ming lan­guages as open source, and there is ev­i­dence that open source pro­jects have higher qual­ity, on av­er­age, than pro­pri­etary ones.

Given enough eye­balls, all bugs are shal­low. I dub this: Linus’s Law.”

–Eric S. Ray­mond, The Cathe­dral and the Bazaar



Every time some­one uses your open source code and files a bug, they are doing QA, for free. Every time some­one sub­mits a patch to your open source pro­ject, they are de­vel­op­ing soft­ware for you, for free. Every time some­one writes a blog post about your open source pro­ject, they are writ­ing doc­u­men­ta­tion for you, for free. And if that blog post is a scathing neg­a­tive re­view, well, even then they are giv­ing you a de­sign re­view, for free.

Shar­ing your work with oth­ers al­lows the en­tire soft­ware com­mu­nity to con­tribute, which makes it pos­si­ble for pro­jects to be­come larger and higher qual­ity than any­thing you could do on your own, es­pe­cially if you work at a small startup. And even if you work at a large com­pany, you’ll find lots of amaz­ing de­vel­op­ers who you can’t hire—maybe be­cause you don’t have the bud­get for it, or those de­vel­op­ers al­ready have jobs, or they live in a dif­fer­ent part of the world—but if you cre­ate a great open source pro­ject, then those de­vel­op­ers may con­tribute to it, for free. For ex­am­ple, more than 3,000 peo­ple have con­tributed code to the open source Ruby on Rails web frame­work, not to men­tion the tens of thou­sands more who have used the frame­work, re­ported bugs, writ­ten blog posts, and cre­ated plu­g­ins. If your com­pany is think­ing of writ­ing its own pro­pri­etary web frame­work, how many peo­ple do you think you’ll be able to ded­i­cate to it?


If you’re a de­vel­oper, the best way to make your­self look good in front of an em­ployer is to share your work. Think of it like in­bound mar­ket­ing for your ca­reer. In­stead of blindly spam­ming your mes­sage to the world (e.g., through send­ing job ap­pli­ca­tions) and hop­ing some­one takes no­tice, you at­tract the em­ployer by shar­ing con­tent they find valu­able. If you can get de­vel­op­ers at that com­pany to read your blog posts, watch your talks, and use your open source pro­jects, they will begin to see you as an ex­pert and are more likely to want to hire you. The work you share be­comes a per­ma­nent part of your résumé. In fact, it’s even bet­ter: as jQuery cre­ator John Resig said on Twit­ter, “When it comes to hir­ing, I’ll take a Github com­mit log over a résumé any day.”

If you’re an em­ployer, it works the other way, too. The best way to make your­self look good in front of de­vel­op­ers is to share your work. If a de­vel­oper has been using your com­pany’s open source code for years, they are more likely to want to join your com­pany and con­tinue using that code. An open source pro­ject is one of the most ef­fec­tive ways to at­tract tech tal­ent, and a far bet­ter job ad­ver­tise­ment than a tra­di­tional job post­ing.


As a de­vel­oper, if I put thou­sands of hours of ef­fort into a pro­ject, I tend to get at­tached to it. It’s my baby. If it’s a pro­pri­etary pro­ject, leav­ing the com­pany is a bit like get­ting a di­vorce and los­ing cus­tody of the kids. It’s painful, and after you’ve done it a few times, it’s hard to be as pas­sion­ate about in­vest­ing in some­thing that isn’t re­ally yours.

How­ever, if you get to give talks about the work, pub­lish blog posts and pa­pers, and best of all, open source your pro­ject, then it’s yours for life. It be­comes a per­ma­nent part of your tool­belt, some­thing you can take with you any­where you go, some­thing you can show to oth­ers, and some­thing you’ll be proud to work on.

In other words, open source pro­jects are sim­ply more fun and more sat­is­fy­ing to work on. And in an era where every­one is com­pet­ing for tech tal­ent, mak­ing a job more fun can be a huge ad­van­tage.

“It may well turn out that one of the most im­por­tant ef­fects of open source’s suc­cess will be to teach us that play is the most eco­nom­i­cally ef­fi­cient mode of cre­ative work.”

Eric S. Ray­mond, The Cathe­dral and the Bazaar


Reasons not to share

Even after read­ing all the above, I typ­i­cally still run into three com­mon ob­jec­tions to shar­ing work:

  • 1. “I don’t have time.”
  • 2. “No one will look at my work.”
  • 3. “Some­one will steal my work.”

Let’s go through them one at a time.

  • I don’t have time

The most com­mon rea­son for not tak­ing 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 re­mem­ber this: busy is a de­ci­sion. 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 im­por­tant dead­line, go to a doc­tor’s ap­point­ment, at­tend a Game of Thrones watch­ing party, or any­thing else you think is im­por­tant. And shar­ing, as it turns out, is ex­tremely im­por­tant if you want to have a suc­cess­ful ca­reer.

In pro­fes­sional sports, gru­el­ing work­outs and in­tense train­ing ses­sions are a stan­dard part of the job. Sim­i­larly, pro­fes­sional mu­si­cians, dancers, and chess play­ers spend hours hon­ing their craft every day. And yet with most of­fice jobs, once you grad­u­ate from col­lege and com­plete a ramp-up pro­gram at your new com­pany, ded­i­cated time for learn­ing and train­ing comes to an end. In other words, if you walk around the typ­i­cal of­fice, al­most every­one 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 min­utes to cre­ate, learn, and share. De­pend­ing 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 pro­ject. I’ve found that this sim­ple rou­tine where I reg­u­larly in­vest­ing a small amount of time in learn­ing—and just as im­por­tantly, shar­ing what I’ve learned—has com­pletely trans­formed my ca­reer.

Make learn­ing and shar­ing a reg­u­lar part of your sched­ule. Find a time that works for you—per­haps just be­fore work, dur­ing lunch, or be­fore bed—and com­mit to it for 20-40 min­utes every day. This might not seem like much time, but think of it like com­pound in­ter­est: a small amount in­vested now grows into some­thing huge over time.


  • No one will look at my work

It doesn’t mat­ter if no one ever reads your blog or uses your open source pro­ject. Writ­ing, speak­ing, and open source, first and fore­most, are learn­ing tools for you. As William Zinsser said in On Writ­ing Well, writ­ing is just think­ing on paper. The pri­mary goal of a blog is to im­prove your own think­ing, so it’s worth doing even if no one reads it. Sim­i­larly, putting to­gether a pre­sen­ta­tion and ar­tic­u­lat­ing your ideas to oth­ers will help clar­ify your own thoughts. And as I dis­cussed ear­lier, the work you do to open source your code makes that code bet­ter.

That said, if you prac­tice your writ­ing, speak­ing, and cod­ing, your au­di­ence may grow. It starts with your friends and col­leagues, but slowly, es­pe­cially if you share your work on sites like Twit­ter, Face­book, LinkedIn, Red­dit, and Hacker News, strangers will find your work, share it, and offer feed­back. More­over, on the In­ter­net, where no one sees you in per­son, your iden­tity is writ­ing, speak­ing, and open source. What­ever turns up when I Google your name is who you are. In other words, in the mod­ern world, you are what you share.

And if you’re wor­ried that no one will be in­ter­ested in what you have to say, just re­mem­ber that every­one is at a dif­fer­ent stage in their learn­ing:

“You’d be amazed at how many things you take for granted as ‘com­mon knowl­edge’ are ac­tu­ally brand new to other smart peo­ple. There’s sim­ply too much to know in this world, and we’re all con­tin­u­ally learn­ing. (I hope). Often I’ll get dis­cour­aged be­cause I feel like I’m writ­ing about things that have al­ready been dis­cussed into the ground by oth­ers. The thing I have to re­mem­ber is that there’s a ‘right time’ to learn some­thing, and it’s dif­fer­ent for every­one.

…No mat­ter where you are in your ed­u­ca­tion, some peo­ple will be in­ter­ested in hear­ing your strug­gles. This is an im­por­tant thing to keep in mind when you’re blog­ging. Each per­son in your au­di­ence is on a dif­fer­ent clock, and all of them are ahead of you in some ways and be­hind you in oth­ers. The point of blog­ging is that we all agree to share where we’re at and not poke fun at peo­ple who seem to be be­hind us, be­cause they may know other things that we won’t truly un­der­stand for years, if ever.”

— Steve Yegge, You Should Write Blogs


  • Some­one will steal my work.

Most peo­ple do not have the in­ter­est, time, knowl­edge, pas­sion, or skills to steal your work. As Howard H. Aiken said, “If your ideas are any good, you’ll have to ram them down peo­ple’s throats.” More­over, even if some­one does “steal” ideas from your writ­ing or starts using your open source pro­ject, in most cases, that’s a good thing, as their feed­back and con­tri­bu­tions can make your work bet­ter than you could alone.

The only time it would mat­ter if some­one steals your work is if it al­lows a com­peti­tor to over­take you. This is only pos­si­ble if you give away your pri­mary dif­fer­en­tia­tor. For ex­am­ple, for a com­pany like Google, their pri­mary dif­fer­en­tia­tor would be their search ar­chi­tec­ture—that is, the search al­go­rithms and the mas­sive dis­trib­uted sys­tems that index the web and re­spond to queries. This is their “se­cret sauce,” and not some­thing they are likely to ever share in its en­tirety.

But for just about every­thing else, Google ben­e­fits more from shar­ing it than from keep­ing it se­cret, which is why they have open sourced more than 20 mil­lion lines of code in over 900 pro­jects not di­rectly re­lated to search. They’ve re­leased pa­pers around their search ar­chi­tec­ture too (e.g.PageR­ank, MapRe­duce, and the Google File Sys­tem), as merely hear­ing an idea is not enough to steal it. In fact, if your idea is sim­ple enough that some­one could steal it and beat you just from read­ing a paper or hear­ing a talk, then that idea prob­a­bly wasn’t de­fen­si­ble enough to begin with. Com­pare “I have an idea for a so­cial net­work” to “I’ve de­vel­oped a way to launch ob­jects into space” (from Startup En­gi­neer­ing.) Ex­e­cu­tion is what mat­ters, and that’s a lot harder to steal.

The cul­ture of shar­ing

In just about all as­pects of life, doing great work is not enough to be suc­cess­ful. You also have to make sure other peo­ple know that you’re doing great work. I find that this is an es­pe­cially hard les­son to learn for pro­gram­mers, who tend to be in­tro­verted and cyn­i­cal of any­thing that looks like mar­ket­ing or self-pro­mo­tion. But the good news is that shar­ing your work is a vir­tu­ous cycle that can dra­mat­i­cally im­prove both the work it­self and your abil­i­ties. And once you re­al­ize that shar­ing the work isn’t an extra step, but an in­te­gral part of the work it­self—just as writ­ing doc­u­men­ta­tion and tests is an in­te­gral part of writ­ing code—you’ll find more suc­cess in many as­pects of your life, in­clud­ing find­ing jobs, earn­ing pro­mo­tions, at­tract­ing cus­tomers, and hir­ing cowork­ers.

The cul­ture of shar­ing is one of the rea­sons the soft­ware in­dus­try and Sil­i­con Val­ley have been so suc­cess­ful. Com­pared to some­thing like Wall Street, where se­crecy is king, the tech in­dus­try is re­mark­ably open. And when we all share, we all win. Or, to para­phrase Isaac New­ton, in a cul­ture of shar­ing, we can all see fur­ther by stand­ing on the shoul­ders of gi­ants.

This is why I give talks, open source code, and write blog posts (in­clud­ing this one): by shar­ing what I know, I learn new things my­self, and can see a lit­tle bit far­ther. I’d love to hear your thoughts!


Yev­geniy (Jim) Brik­man is the au­thor of Hello, Startup and the founder of Grunt­work, a com­pany that spe­cial­izes in help­ing new star­tups get off the ground. Pre­vi­ously, he spent more than a decade at LinkedIn, Tri­pAd­vi­sor, Cisco Sys­tems, and Thom­son Fi­nan­cial. He has a BS and Mas­ters in Com­puter Sci­ence from Cor­nell Uni­ver­sity.


September 28, 2016 / by / in , , , , , , ,

Leave a Reply

Show Buttons
Hide Buttons