Skip to Content

Defining "Philosophically Open-Source"

Whenever I go to tell someone about one of the many projects I’m working on at any given time, I almost certainly will toss out the phrase “philosophically open-source”.

Defining what exactly that means is a bit trickier than just saying it. Let’s look at what makes a project open-source, and see how that contrasts with one that is philosophically open-source.

The Open Source Initiative has a pretty good definition of open-source, which I’ll excerpt from below:

1. Free Redistribution - The license shall not restrict any party from selling or giving away the software

So, the thing has to be free like “free drink with purchase”.

…The program must… allow distribution in source code as well as compiled form…

The code behind the thing has to be available.

… The license must allow modifications and derived works…

Other folk are permitted to make a new thing out of your thing.

There’s some more specifics in the actual definition, and some new additions about how you must not discriminate, either against individuals or certain fields. But what I want to highlight is the recurring little phrase “must allow”.

To be open-source, a product must allow for free distribution & modification.

To be philosophically open-source, a product must encourage free distribution & modification.

It isn’t just enough to allow someone to improve the source code - you should encourage it, by providing systems & channels to assist them. Which means that as a developer, releasing a philosophically open-source product means not just agreeing to release the source code, but agreeing to serve as the product’s manager.

As with almost anything where the word “philosophy” is brought in, defining the difference between “allow” and “encourage” can be a bit tricky.

But there are a few things that I think can be stated pretty concretely, giving us a good working definition of philosophically open source:

“Philosophically Open-Source” Definition

  1. Encourage Free Distribution
    • The license should be the most freeing available (currently the Unlicense), and the software should be packaged for distribution through common package repositories.
  2. Encourage Collaboration
    • The software must include guidelines for contributing bug reports & patches, and have provisions that work against discrimination.
  3. Encourage Derived Works
    • The software must include instructions for creating a fork of itself.
  4. Open-Source Stack

Editorial and License Information

My name is emsenn and I wrote this essay for the benefit of the commons. To the extent possible under law, I have waived all copyright and related or neighboring rights to it. If you're viewing it on a remote server, you're encouraged to download your own copy. Essays like this are made possible with financial support from readers like you. Thank you. To read more of my work and to learn more about me, visit