Frequently Asked Questions

Super Source is a registration platform for software projects. For too long, open source projects have been run for free, without even knowing who's using the project. With Super Source, project maintainers learn who their users are. Super Source also includes two optional features: a platform to sell licenses, and a contributor license agreement manager.

Sign up to get started, and feel free to send us a message with any questions.

Projects add the Super Source library to their project (currently available in Ruby, Python, and JavaScript), declaring whether to raise an exception, have a warning notice, or manually explain how to register. When an end user first uses the project, they receive the notice about registering with Super Source. Once registered, they no longer will see the notice. If they have teammates, only one member needs to register.

An internet connection is only needed once, at the time a user first installs the project. At that point, they register their email address with Super Source, which saves a token locally in a file. If they have teammates, this file may be checked in to version control. Thereafter, the user never needs an internet connection, so long as the file exists.

Selling licenses lets projects earn money, allowing them to accomplish more overall, and operate sustainably for the long-term.

Open source software is much like a public good. Public goods, in the economic sense, are shared amongst a community for the benefit of the whole. The classic example is a lighthouse: every ship enjoys the benefit of the lighthouse just by sailing near it. Unfortunately, public goods are also susceptible to the free rider problem, where those who benefit from the resource fail to pay for them, because there is little incentive for them to do so. This leads to under investing in the resource. In open source, this manifests itself by projects having little to no revenue, yet being expected to provide support, bug fixes, and new features for a vast number of companies.

The Heartbleed bug of 2014 is representative of how we as a community have under invested in open source. Before the Heartbleed bug, OpenSSL only received around $2k in donations per year, even though it's relied on by pretty much every company online, including Microsoft, Facebook, and GoDaddy. Talk about a free rider problem!

There's a simple solution: ask companies to pay for a license, then use the funding to support further development of the project. The method is simple, straightforward, and deserves to be more prevalently used.

The following licenses would work: the Super Source License, Business Source License, Fair Source License, or your own custom license.

The Super Source License is comparable to a license you'd typically find with commercial software.

By purchasing a license, you support the continued development of that project. This is important because it helps the project improve with new features, bug fixes, better documentation, and long-term sustainability.

You also get the assurance of a commercially friendly license.

When companies buy a license, they pay for it online at the Super Source website. A fraction of the funds go to Super Source to cover credit card processing fees and continued development, determined as part of an agreement by you and Super Source. The rest is delivered to your project.

The license key is emailed to the same email used when acquiring the license. If you have lost it, you may contact us.

No, not really. It's a myth that the tragedy of the commons applies to open source software, or for that matter, Super Source. As Eric S. Raymond wrote in The Cathedral and the Bazaar:

"...using software does not decrease its value. Indeed, widespread use of open-source software tends to increase its value, as users fold in their own fixes and features (code patches). In this inverse commons, the grass grows taller when it’s grazed upon."

Note that the tragedy of the commons is different from the free rider problem. The tragedy of the commons would lead to overutilization, if true. The free rider problem, on the other hand, leads to underinvestment. Despite theoretical arguments that the free rider problem wouldn't apply to open source, history has proven otherwise. For example, the Heartbleed bug made it painfully clear that the free rider problem results in underinvestment in open source.

It depends. If you keep the project available under an open source license, but also make it available under a commercial license, then yes, it is still open source. This is called dual licensing. Alternatively, if you sell licenses to code that requires a paid licenses, then it is no longer open source. Super Source supports both use cases.

For legal clarity, many projects require contributors to sign a Contributor License Agreements (CLAs) in order to merge their code into the codebase. The Contributor License Agreement grants the project owner a non-exclusive license to the contributions. Contributor License Agreements are typically required by all large companies, as well as many smaller companies. Super Source has an optional CLA manager that projects may enable to keep track of who's signed the CLA, and a bot to post on Github pull requests about the CLA status. Contact us if you're interested in this feature.