It's important that we also reveal & spread light on the computing, on opening the source. But the data underneath is highly occluded, highly captured, and is the root thing we want empowerment over. The tools are good to open, but the key radical movement that feels like it just has to happen is opening the thing the tools work on, the data. Once we can start to actually grasp what's underneath interface, once the data itself is FAIR, we open up human agency. That's the first start for freedom respecting technology.

I think FAIR lights the fire of interest, re-opens the window for enlightenment to flow again. And that will be compelling for people.

FAIR: Findable, Addressable, Interoperable, Resuable. https://www.go-fair.org/fair-principles/

Hat tip to one Dorian Taylor for the reference.

This is just one of a million angles, but it does make me think of the semantic web. There's a lot of business & data & research folks in this sector, but one of the core lessons is that things should have URLs; core axiomatics of the web itself (https://www.w3.org/DesignIssues/Axioms.html). Even the littlest drop of rdfa or microdata often starts with marking up different elements of the page to give them their own URI/URLs, making it explicit that the page is made up of many different objects. This is a low key change, but sets the seeds to let the web be more than opaque pages, to let the web be a thing of many objects.

The contribution graph of most projects looks like a power law, this is a failure of open source. We need to lower the barrier to entry to flatten the contribution graph and to enable mass collaboration. And that goes through a focused effort on what they call open knowledge.

And I think that implies giving up on some agile principles for most open source projects. You cannot rely on people over documentation, for example, when the potential contributor pool has 1000s of developers and the knowledge is held by one guy in Wyoming who does it part time after work.

I feel immensely gratified. I already do this except for one thing.

That one thing that I don't do is breaking down the docs into subsets. The reason I haven't is because the docs are small enough for me to not care. (3MB total download each for releases of both major repos, and that includes everything, including source, tests, and docs.)

But otherwise, I do this. My docs are in a Markdown-like format (so you technically don't even have to build them), they contain everything you need to know, they are pre-built or need only FOSS tools to build (which I will actually replace with tools contained in the repo itself), they even include how to hack on my code: a braindump of design, implementation, and my mindset when I hack.

That doesn't mean I can't make an online version. I can. However, people who download the repos can still use it offline.

(Another thing I need to do is have a link from the online version to the source, probably in the footer.)

I highly suggest everyone do this. It has delighted my users.