Why Your App Should be Open Source – by Peer.FM

Many organizations have banned the use of GPL software in their codebases; here’s why I chose the opposite approach.

Software Quality

Releasing your software under an open source license will quickly expand your developer team. Immediatelyafter we launched, for example, Peer.fm received multiple pull requests (code contributions) on GitHub

as Eric Raymond states, “given enough eyeballs, all bugs are shallow” (Linus’s Law).

Rather than staying limited to a small team (perhaps even a single developer), fostering an open source community will open the doors to potentially unlimited contributions from other developers, and even from your own more technically inclined users; this type of feedback is thus a great indicator of major pain points your users have with your product. Even among your users who aren’t programmers, the GitHub issues system is an incredibly useful tool for tracking bug reports and feature requests.

Closed source software, by contrast, forces users to blindly trust the team behind it; I bet you can still remember the last time some Web service was “hacked” and one of your passwords was leaked in plain text as a result. The very nature of open source causes the likelihood of such carelesspractices to become increasingly feweras the popularity of your software grows.

Competitive Risk

Couldn’t a competitor just steal your code? Under the GPL, if a competitor were to use and distribute part of your code base, they would legally then have to release all of their code under the same licensing. This offers fairly good protection from competitors with proprietary software whose source code they would never want released.

If someone were to fork and redistribute your code, it would simply add to your credibility, and even potentially lead to useful feedback or code contributions; a symbiotic relationship between competing services is definitely possible.

“Regarding matters of competition, I’m definitely at risk for potential brand dilution and/or project failure if another entity were to reuse my code and execute more successfully on the business end; that having been said, if another entity were to pour money into development, the GPL would ensure that it would work in my favour as well.” – Ryan Lester, Founder of Peer.fm

Acquisition Potential

One major concern for a new startup considering this route is whether they will be blowing theirpotential for future acquisition. After all, barring an “acqui-hire” situation, why would a tech giant want to buy your code off you when they can just download it for free on GitHub?
I personally feel that despite the completely open nature of my startup, I would still be protected from a major tech companies taking advantage of my code in their products due to the GPL – unless they were to open source their own code or acquire ownership of mine. In either case, my product is guaranteed to live on, in contrast to the majority of startup which shut down post-acquisition.

That said, if my startup were to take off as a community-driven project, a hypothetical acquisition event would force me to sort out which code I could and couldn’t legally sell ownership of.

Project Control

Another potential tradeoff is that I am more limited in terms of control and potential strategies (e.g. for monetisation), in that if I were to add something like ads, which the community were to perceive as degrading to the quality of the product, then I would be immediately forced to compete with an arbitrary number of forks that each have the aforementioned degrading quality removed.

Since this would be detrimental to the community, having this in the back of his mind is definitely a powerful internal check against release changes.

In short, for my startup, open source was the only way to go. Just the exposure and developer support alone helped my product get to the market.