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.
We have the following goals regarding our products and services:
This last bullet point – protection from other companies selling our work – may sound controversial but we found it to be necessary to ensure Sentry as a company can survive and keep working on Sentry the product.
All these lead us to use a somewhat extraordinary license, the Business Source License, which we best describe as eventually open source. Although this license is not among the OSI-approved licenses and does not fit the strict OSI definition of open source, it gives you all the freedom provided that you are not offering a commercial version of Sentry. Even more, it removes this one limitation after a 36-month grace period, turning into a bare Apache-2.0 license eventually. You can read more about our license and the whys behind it on our blog.
Since we strive to keep everything as open and free as possible, we are only using the more restrictive BSL-1.1 license on the Sentry backend code. Here are the 3 licenses we use:Business Source License 1.1 (BSL-1.1)
All components powering the main Sentry backend use BSL-1.1 license which limits their usage in a commercial Sentry-like offering. If you need to use some of this code without the BSL license or want to commercialize Sentry, reach out to us at email@example.com. Here are all the projects covered under our BSL-1.1 license:
Sentry's default license of choice is the permissive but protective Apache-2.0 license. This license is OSI-approved, widely adopted, and still has some safe-guards like attribution requirement or patents protection. Any new projects are licensed under Apache-2.0 unless there's a concern around GPL-2.0 compatibility for adoption.The MIT License (MIT)
We use the MIT license as a fallback for the Apache-2.0 license where we need to reach to a wider audience, due to the GPL-2.0 incompatibility. This is the license we use for all our SDKs.
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?”:
So no, open core ≠is not the same as open source. It’s essentially a marketing strategy for proprietary software.
People sometimes ask why Sentry is an open source company. 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 an open source company 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.