5 ms·

This. There is really no downside to doing this, and lots of potential upside. I honestly think most companies could do this with zero effect to their bottom li

This. There is really no downside to doing this, and lots of potential upside. I honestly think most companies could do this with zero effect to their bottom line.

wmichelin 10y ago
If your code is bad, then there's risk of making security vulnerabilities more visible. Not that that's a good reason to avoid open sourcing, but it's a reason.
- IgorPartola 10y ago
  Which is also a good reason to open your code and let those that know better help you fix it.
  - Alupis 10y ago
    > Which is also a good reason to open your code and let those that know better help you fix it. This is a fantastic mentality, but unfortunately doesn't really play out in reality. I'm a huge Open Source fanboy, but we need to be "real". How many people are really going to read every line of every open source program? Very-few-to-none is the real answer. Massively popular software gets eyeballs, but few others do. Most of us just use the software and trust/hope someone else reviewed it for security et al. The problem with that is, we are all trusting/hoping someone else did a review, but that someone else is trusting/hoping someone else did a review.
    - IgorPartola 10y ago
      How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful feedback at a fraction of the cost of a full on audit.
      - Alupis 10y ago
        I agree with the sentiment of your post, however I believe it is based on an ideal world, which we don't live in. > How many of the people that do review your code would exploit it vs reporting it to you By nature, attackers would be reviewing your code as well. > Combine it with a bounty program The overwhelming majority of Open Source software was created-by and is curated-by a single person who makes negative profit by working on the software for free in their spare time. Even some of the most popular projects are still total losses for their curators. You're not going to get bug bounty programs here. For example, take a look at Crosstool-ng[1] (a popular project used to build cross-compilers for various architectures). Companies and individuals are all using this project to build cross-compilers that they trust to build other software with. A bug in Crosstool-ng could propagate into bugs in the compiled software it produces. Bryan Hundven does most of the heavy lifting on this project by himself, and as far as I know, he's paid nothing for it. You're not going to get a bug bounty program here either. Heck, it's doubtful even a project as large as the Linux Kernel would be able to afford an ongoing bug bounty program. They're trying with the Linux Foundation and the Core Infrastructure program, but how many years before did it have none of that? Essentially, these programs only work for commercially-backed software, which is only a small sliver of open source software. [1] https://github.com/crosstool-ng/crosstool-ng https://github.com/crosstool-ng/crosstool-ng
        IgorPartola 10y ago
        But I am specifically talking about companies with closed source apps and services open sourcing them, not tools that are already open. Examples are Uber, AirBnB, and Groupon, not gpg or OpenSSL.
        Alupis 10y ago
        > But I am specifically talking about companies with closed source apps and services open sourcing them Ah, I see. I misunderstood. Yes, I think we are in agreement then, although I have my doubts most companies want their "secret sauce" or code-indiscretions flapping in the wild.
  - bigiain 10y ago
    If widely used and critically important open source projects like OpenSSL can have latent security bugs lying in them for years (Heartbleed?) - I don't think it's practical to assume "the open source community" will security-audit and send pull requests for your "open sourced" product app. If you want your code security audited, pay a reputable firm to conduct an audit. Throwing it up on Github and thinking "the good guys" will spend time looking and contact you for free when they discover problems is misguided at best.
V-2 10y ago
> This. There is really no downside to doing this, and lots of potential upside. I honestly think most companies could do this with zero effect to their bottom line. And - if the code is good, clean, modern - attracting talented coders that way. Showing me such code is million times more convincing than all the usual slogans
exclusiv 10y ago
Not that it would be easy to compete with Kickstarter anyway, but what about enabling clone competitors?
- krschultz 10y ago
  The apps don't really matter. I was the Android lead at Gilt and we often talked about open sourcing our app. We ended up open sourcing our iOS one (https://github.com/gilt/cleanroom https://github.com/gilt/cleanroom). We were a company with a thousand employees, most of them not writing code. If you wanted to compete with us, copying our app was 5% of the overall effort, and what would you really get from our app that connects to our (closed source) backend anyway? The upside was enormous in terms of recruiting, retention, and keeping engineers excited. Kickstarter is in an even better position. Their defendable advantage is the network effect of being the go-to place for crowd sourcing.

This. There is really no downside to doing this, and lots of potential upside. I honestly think most companies could do this with zero effect to their bottom line.

wmichelin 10y ago

If your code is bad, then there's risk of making security vulnerabilities more visible. Not that that's a good reason to avoid open sourcing, but it's a reason.

IgorPartola 10y ago
Which is also a good reason to open your code and let those that know better help you fix it.
- Alupis 10y ago
  > Which is also a good reason to open your code and let those that know better help you fix it. This is a fantastic mentality, but unfortunately doesn't really play out in reality. I'm a huge Open Source fanboy, but we need to be "real". How many people are really going to read every line of every open source program? Very-few-to-none is the real answer. Massively popular software gets eyeballs, but few others do. Most of us just use the software and trust/hope someone else reviewed it for security et al. The problem with that is, we are all trusting/hoping someone else did a review, but that someone else is trusting/hoping someone else did a review.
  - IgorPartola 10y ago
    How many of the people that do review your code would exploit it vs reporting it to you? Combine it with a bounty program, and chances are you will get useful feedback at a fraction of the cost of a full on audit.
    - Alupis 10y ago
      I agree with the sentiment of your post, however I believe it is based on an ideal world, which we don't live in. > How many of the people that do review your code would exploit it vs reporting it to you By nature, attackers would be reviewing your code as well. > Combine it with a bounty program The overwhelming majority of Open Source software was created-by and is curated-by a single person who makes negative profit by working on the software for free in their spare time. Even some of the most popular projects are still total losses for their curators. You're not going to get bug bounty programs here. For example, take a look at Crosstool-ng[1] (a popular project used to build cross-compilers for various architectures). Companies and individuals are all using this project to build cross-compilers that they trust to build other software with. A bug in Crosstool-ng could propagate into bugs in the compiled software it produces. Bryan Hundven does most of the heavy lifting on this project by himself, and as far as I know, he's paid nothing for it. You're not going to get a bug bounty program here either. Heck, it's doubtful even a project as large as the Linux Kernel would be able to afford an ongoing bug bounty program. They're trying with the Linux Foundation and the Core Infrastructure program, but how many years before did it have none of that? Essentially, these programs only work for commercially-backed software, which is only a small sliver of open source software. [1] https://github.com/crosstool-ng/crosstool-ng https://github.com/crosstool-ng/crosstool-ng
      - IgorPartola 10y ago
        But I am specifically talking about companies with closed source apps and services open sourcing them, not tools that are already open. Examples are Uber, AirBnB, and Groupon, not gpg or OpenSSL.
        Alupis 10y ago
        > But I am specifically talking about companies with closed source apps and services open sourcing them Ah, I see. I misunderstood. Yes, I think we are in agreement then, although I have my doubts most companies want their "secret sauce" or code-indiscretions flapping in the wild.
- bigiain 10y ago
  If widely used and critically important open source projects like OpenSSL can have latent security bugs lying in them for years (Heartbleed?) - I don't think it's practical to assume "the open source community" will security-audit and send pull requests for your "open sourced" product app. If you want your code security audited, pay a reputable firm to conduct an audit. Throwing it up on Github and thinking "the good guys" will spend time looking and contact you for free when they discover problems is misguided at best.

V-2 10y ago

> This. There is really no downside to doing this, and lots of potential upside. I honestly think most companies could do this with zero effect to their bottom line. And - if the code is good, clean, modern - attracting talented coders that way. Showing me such code is million times more convincing than all the usual slogans

exclusiv 10y ago

Not that it would be easy to compete with Kickstarter anyway, but what about enabling clone competitors?

krschultz 10y ago
The apps don't really matter. I was the Android lead at Gilt and we often talked about open sourcing our app. We ended up open sourcing our iOS one (https://github.com/gilt/cleanroom https://github.com/gilt/cleanroom). We were a company with a thousand employees, most of them not writing code. If you wanted to compete with us, copying our app was 5% of the overall effort, and what would you really get from our app that connects to our (closed source) backend anyway? The upside was enormous in terms of recruiting, retention, and keeping engineers excited. Kickstarter is in an even better position. Their defendable advantage is the network effect of being the go-to place for crowd sourcing.