Closed source, secrecy and trust

Arseni Mourzenko
Founder and lead developer
161
articles
November 6, 2014
Tags: quality 29 rant 33

Most com­pa­nies which pro­duce source code don't re­lease it in the wild. They are hid­ing it, pro­tect­ing it against unau­tho­rized ac­cess, ob­fus­cate it, make you sign NDA and ask them­selves how they can be sure that the code will nev­er ever reach in­ter­net.

When asked why they aren't re­leas­ing source code pub­licly, peo­ple are usu­al­ly ashamed, and then start to quote dif­fer­ent rea­sons.

In essence, they don't have valid rea­sons to not re­leas­ing source, or, rather, they have rea­sons, but won't ad­mit them, some­times even to them­selves.

At Pel­i­can De­sign & De­vel­op­ment, de­spite the ori­en­ta­tion to­wards open­ness since 2013, a large part of the cor­po­rate source code re­mains se­cret. Those are the true, se­cret rea­sons why:

  1. The qual­i­ty of the source code is too low. It is a case for lega­cy source, as well as pro­jects cre­at­ed with­out qual­i­ty in mind. Re­leas­ing such source may harm the im­age of the com­pa­ny and the au­thors. For ex­am­ple, I wouldn't ap­pre­ci­ate be­ing asked ques­tions about my own old, crap­py code dur­ing an in­ter­view.

  2. The source code con­tains known se­cu­ri­ty bugs. Solv­ing them takes time, so mean­while, the code re­mains hid­den.

  3. The source is stolen from some­where or is used in a way which is not per­mit­ted by the li­cense.

  4. The source con­tains in­for­ma­tion which shouldn't be in the source, such as pass­words or pri­vate keys.

As you can see, the real rea­sons are much less at­trac­tive than the ones from the first list above. In­deed, the ones from the first list don't make real sense for most com­pa­nies:

In­no­va­tion

Se­ri­ous­ly, stop us­ing this word. If you're re­al­ly in­no­v­a­tive, you don't need to put this word in every sen­tence of your mar­ket­ing jib­ber-jab­ber. If you're an or­di­nary com­pa­ny, I'm sor­ry, but you're not in­no­v­a­tive. At best, you're up to date with tech­nol­o­gy. Of­ten, the mar­ket­ing term in­no­va­tion is used by small com­pa­nies to in­di­cate that they dis­cov­er, from times to times, what was al­ready used by larg­er com­pa­nies for decades. The ap­pro­pri­ate ex­pres­sion would be rein­vent the wheel, not in­no­vate.

I'm tired if cus­tomers who make me sign NDA be­fore telling their su­per in­no­v­a­tive idea, such us “Let's cre­ate a web­site where peo­ple can post short mes­sages about news” or “Any com­pa­ny would be ex­cit­ed by a web­site which will uni­fy all their cor­po­rate ap­pli­ca­tions and in­for­ma­tion in one place”.

A year ago, I had a cus­tomer who asked me to sign NDA in or­der to work on a se­cret pro­ject. A week ago, I launched Health app in­stalled with Win­dows 8.1 in or­der to see what it is about. It ap­pears that a part of it is very sim­i­lar to my cus­tomers' pro­ject. With the dif­fer­ence of be­ing done bet­ter. With bet­ter graph­ics. More in­tu­itive. Faster. I'm pret­ty sure that this NDA-cov­ered pro­ject was nev­er re­leased, or is re­leased but not used by any­one.

If only one could talk about his pro­jects to oth­ers, he would have a chance to learn lots of things. Such as that the pro­ject sucks. Or that it al­ready ex­ists.

As a side note, I work in a so-called “R&D de­part­ment” in a com­pa­ny. There is no re­search, and there are no re­searchers. There is prac­ti­cal­ly no de­vel­op­ment nei­ther. Just pro­gram­ming and de­bug­ging.

Clones

Have you seen an open source pro­ject which one can seam­less­ly copy and use as his own in no time? Mak­ing a prod­uct from the code base of a com­peti­tor re­quires time. The larg­er is a prod­uct, the larg­er would be the ef­fort. Not count­ing the fact that in most cas­es, the code base is un­us­able and won't even com­pile.

It's as easy as that: ei­ther your com­peti­tor makes an ef­fort, cre­ates ad­di­tion­al val­ue, and sells a bet­ter prod­uct than yours, or he achieves to sell the same stuff than you, but bet­ter.

In the first case, re­mem­ber that you're the one who knows the code base the best, so you have un­doubt­ed­ly this ben­e­fit over your com­peti­tors, be­ing able to re­spond faster to new de­mand.

In the sec­ond case, you're sim­ply a bad sell­er. Deal with it.

Se­cu­ri­ty

If re­leas­ing the source code makes your prod­uct less se­cure, you're do­ing se­cu­ri­ty wrong. Dude, go learn some ba­sics of se­cu­ri­ty, se­ri­ous­ly.

Cost

Wait, I al­ways thought that GitHub and Code­plex were free.

What ac­tu­al­ly costs mon­ey is to hire lawyers to write the NDA, to spend meet­ings dis­cussing how to pro­tect source code, to waste mon­ey on pro­tec­tion soft­ware, etc.

Im­pli­ca­tions

In oth­er words, when some­body claims he has se­ri­ous rea­sons to hide source code, he ac­tu­al­ly lies, and in­di­rect­ly ad­mits that he wastes mon­ey and time. Your mon­ey, if you're a cus­tomer. Your time, if you're a free­lancer.

When you can't see source code, you can't be sure it's good. Pre­sump­tion of in­no­cence doesn't work here: if there is no proof that the code is good, as­sume it's bad, since by de­fault, the code is al­ways bad and it re­quires ad­di­tion­al ef­fort to make it good.

Se­cre­cy on this lev­el has one and one only im­pli­ca­tion: the lack of trust.