What does Open Source actually mean?
It’s a frequent debate that boils down to a set of characteristics of software development, contribution, and distribution, as well as the supporting community.
By definition, the term "open source" refers to something people can modify and share because its design is publicly accessible. In other words, software for which the original source code is made freely available and may be redistributed and modified.
Although open source originally defined a specific approach to programming, it also covers the principles of open exchange, collaborative participation, rapid prototyping, transparency, meritocracy, and community-oriented development.
Does Open Source mean free?
In the world of software, free applications are often inferior applications. That’s especially common for business technology, where an Enterprise upgrade may be feature-complete with robust integrations and a more manageable interface, but also unapproachably pricey.
This is not necessarily the case with open source software. There is no difference between the version of Sentry you maintain on your servers and the version we support as a cloud service. Everything runs off of the same code, which is available on GitHub.
What about Open Core? Is that the same thing?
No, not at all. The two are vastly different. According to Ashesh Badani of Red Hat in ”Open Source or Open Core: Why Should You Care?”:
The open core development model, where vendors open only portions of their software and then surround the remainder with proprietary-by-vendor offerings, simply does not work. It is a narrowly-cast version of open source that only stands as a matter of corporate convenience for technology providers who continue to hold on to antiquated proprietary offerings, delivering minimal innovation.
So no, open core is not the same as open source. It’s essentially a marketing strategy for proprietary software.
Why are we Open Source?
People sometimes ask why Sentry is open source. However, they are typically asking about our business model: conversion funnel, product roadmap, monetization strategy. In our experience as engineers and as professionals, there is no other choice but open source for building a viable software company serving modern development cycles.
As a mantra, Sentry is open source because the right to learn and to share what is learned with others is fundamental to product growth and relevance.
Open source code can be updated locally by any developer and changed often (even replaced as needs shift). It’s pliable to each user’s specific objectives and use case, and any modifications can be made available to the entire community.
When a user is dependant on a vendor, making changes typically carries substantial costs, which are passed on to the customer. Infrastructure or architecture complexity also usually contribute to high switching costs (and high service costs).
Software that’s viewable by everyone out in the open inherently contains incentives to find and address security and other vulnerabilities more quickly. Compliance isn’t beholden to the vendor’s ability to hire dedicated engineers.
Security through obscurity often hides issues. If a product is closed from public view, those outside the company have little idea how many bugs or security issues it may contain. Additionally, compliance reviews are very difficult and expensive.
Being able to share and communicate data between systems and services is essential to long-term use and user outcomes. Openness to integrations is a basic tenet of modern software and key to the user experience.
Restrictions on the use of proprietary software are spelled out in an end user license agreement, typically prohibiting modifications to enable use with certain other technologies (or those upgrades are only available for a fee).
Open source software is “free like a kitten,” requiring care and support from an active community. A common point of reference — the code — is a starting point for users to coalesce and determine direction and growth.
When companies restrict certain functionality or features to a paid version of their software, there is little opportunity to build a community, since groups of users have different experiences dictated by the vendor.
There are few barriers to modifying open-source packages for different contexts, such as libraries or SDKs for your framework of choice. Open source even makes it easier to find community partners to work on projects that benefit everyone.
Getting modifications made to accommodate your application or systems usually depends on a vendor’s existing roadmap (or your ability to pay). Proprietary software rarely has flexibility to support emerging (or legacy) needs.
Open source is not just a try-before-you-buy sales model. It encourages users to learn by using the software at scale and lower their own barriers to widespread adoption. It also helps with staff retention and onboarding new team members.
Most vendor-specific software (even open-core and SaaS) not only requires payment prior to implementation, but it also limits the access users have to learning before adoption, often requiring expensive training, certification, and integration.