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.