Hi Rob, it was me.
Thanks for coming forward as a person.
The post had nothing to do with perceived competition; I also don't consider you competitive.
Great. Then this is an intellectual discussion and we can steer clear of attacks and simply disagree on specific things if necessary.
I wrote what I wrote because it seems highly irresponsible to market something as "secure and private" when it is impossible to audit the source—we're in the post-Snowden era here, are we not? I don't mean to pick on you guys in particular, you seem like a nice, well-intentioned bunch. But if you truly care about privacy and security, then I don't see how you can disagree with my premise. The old way of doing things has had its day.
The lynchpin of these conversations is usually in the individual interpretation of the word "secure." To clarify, your premise is the word 'secure' may only be used if the source is open, correct?
As I've mentioned, for some folks, that means they can view the source, or the source is available for someone you trust to consult. We're all for these folks and point them to use OTR messaging and PGP. These kind of people often are ok dealing with the UX downfalls and limitations of these systems.
Most folks don't compile Linux for themselves. So they do treat OS X or their (hopefully) updated copy of Windows as offering security and privacy. I think they have good reason to feel that way, particularly with iOS--even though that is closed source.
I will continue to encourage you to re-think this strategy.
The feedback has been received, thank you.
Can you explain to me why "startup" and "open source" are at odds? I don't really follow.
I won't do nearly as good of a job as dreeves has in compiling Yehunda Katz and AParecki's considerations in
this HN thread.Costs of open sourcing your startup:
1. Reviewing all of the code that you want to open source for secrets that could compromise security.
2. Improving parts of the code that are embarrassing or too coupled to infrastructure that isn't going to be made open source.
3. Additional communication overhead for communicating with the open source community so that contributors don't do work that you're already working on.
4. Time spent triaging and working with features that may not have been high internal priorities (or risk pissing off the open source ecosystem).
5. A general willingness to cede control over the precise direction and priorities to a larger group of open source people.
Aaron Parecki adds:
6. Support costs of helping people get their dev environments set up.
But Yehuda, obviously, is in favor of open-sourcing as long as you understand those costs, and lists these advantages, most of which the article also notes:
1. Gaining additional contributions from open sourcers that would have been expensive or technically impossible to do in-house.
2. A vibrant community of people that are interested in the product, its direction, and are knowledgeable in the implementation.
3. People willing to do cleanup work in order to become familiar with the project and become contributors.
4. Getting insight into product direction by people willing to put their money where their mouth is and dedicate time to implementation (this is the flip side of some of the negative above).
5. A recruitment pool that is already familiar with the product and its implementation.
I'd add to that a security audit in advance of open sourcing the project to protect existing users.
Depending on the project size and age, all that may be low cost. It may even be a cost you're happy to deal with if you feel it is a major value proposition to the audience you're after.
A few more reasons:
- Gliph's iOS app is completely native, and largely front-end UI (where heavy lifting is done by servers) Objective-C is complex code that is original and valuable and not something we want easily copied by competitors.
- Server-side, we do incorporate open source libraries, however the great majority of Gliph platform is
original software . The web application is complex, powerful and valuable intellectual property that
we have worked very hard on for years. While our goal is to make a big contribution to society, Gliph is not a charity.
- The Coinbase and Blockchain API's have undocumented peculiarities that we have learned with great pain over time. At this point, it is up to other startups to also figure these issues out to be competitive in this space.
But the number one reason right now is that I personally do not think most regular internet users can explain what it means for software to be open source, let alone how software is built. They just want to be able to get things done. They want reasonable security and privacy precautions taken without the details. We take care of that for them. Our users do not write in to us ask for open source code, they write in asking for new and better features.
So startups that deal with Bitcoin have a dual problem: they must provide security even though it's value is only understood when there is an intrusion, and they must also actually create a product of real value that gets adopted.
To turn this back to Gliph, we have built an incredibly powerful platform that is just barely scratching the surface for our intent. While it may not meet your particular requirements of security, the platform is secure and handles data securely with privacy controls that are simply not available on any other product right now.
On the topic of Privacy, our team thought carefully about
Gliph's privacy policy which is written in a way that anyone can read. Not just people who know how and have the luxury of spending time reading code for this purpose.
