In Search of the Free and Free

Say what you will about the world we are living in, there is something extraordinary about being able to sit down with an idea and, a few hours later, have a piece of software taking shape in front of you.

AI and large language models have made that experience familiar to many more people. Since ChatGPT appeared in November 2022, the tools have kept changing, sometimes faster than we can develop sensible habits around them. Every day seems to bring another application, another experiment, another free trial.

I share the excitement. I also find myself returning to an older question: what do we mean when we call software free?

A download can cost nothing while leaving its user entirely dependent on its developer. A trial can be generous and still expire. We can become remarkably attached to tools whose future we have almost no say in.

The Free Software Foundation gives the word a more demanding meaning: the freedom to run a program, understand it, change it, and share it, including the changes. Price is a separate choice. Free software can be sold.

I would like Binary Markdown to be free in both senses.

Lately, I have been rereading Eric S. Raymond’s The Cathedral and the Bazaar. There is an energy to that writing which survives the age of its examples: people discovering what becomes possible when a project opens itself to the attention of others.

In Raymond’s account of Linux, the growing availability of the Internet helped turn the world into a potential community of collaborators. Someone elsewhere could see what you were doing, recognize a problem, and know something you did not. The challenge was to make room for them.

That still seems a remarkable way to build anything.

Our tools are now very different. A person who once might have stopped at reporting a bug may be able to investigate it, test an idea, and propose a patch. An unfamiliar codebase may be less intimidating with something available to explain it—provided we remember that the explanation can be wrong.

The need for judgment remains. So does the possibility that a useful insight will come from someone we have never met.

Binary Markdown owes its existence to that possibility. Its visual editor and much of its functionality come from Any Markdown, by raggbal and its contributors, released under the MIT license. Their work gave us somewhere to begin.

There is something grounding about maintaining a project with that history. Open source becomes quite concrete when you are working inside code that somebody else chose to share.

For Binary Markdown’s continuing development, we chose AGPL-3.0-or-later, preserving the MIT grants that apply to the inherited work. I want the freedom to improve this software to survive its journey beyond our repository. The AGPL’s copyleft and source-sharing requirements give that intention a legal form, including provisions for modified software used over a network. Those requirements have a defined scope; the license deserves to be read.

You can fork the project. You can disagree with our priorities and develop your own version.

I find that reassuring.

We have already had an outside contributor. zhangxiaozhuang398-max submitted a change adding outline reading-position tracking and code-block deletion, which was merged into the project.

At this scale, a contribution like that stands out. Someone spent enough time with the software to notice what could be better, then spent more time helping improve it.

There is a person behind a pull request. It is easy to forget that when we start counting stars, downloads, issues, and commits.

Raymond writes about the practical strength of collaboration. The free-software movement insists on the freedoms people should have. I keep finding reasons to care about both.

I also think the arrival of increasingly capable AI tools makes the maintainer’s attitude more consequential. Code can arrive quickly. Understanding it takes whatever time it takes. A patch may be helpful, mistaken, ambitious, or simply outside the direction of the project. We still have to read it, test it, and respond with care.

Users know things about our software that we cannot learn by generating another feature. They encounter it in the middle of their own work, with their own documents and expectations. A small frustration that barely registers in development may interrupt them every day.

I want to leave room for those experiences to change the project.

And eventually, perhaps, for other people to lead it. Interests change. Time becomes scarce. A project can outlast the enthusiasm that started it. If we reach that point, I hope we make the effort to find capable successors and leave them something understandable to inherit.

For now, Binary Markdown is small, and there is plenty to improve. I am glad it already belongs to a history of people building on one another’s work.

Whatever our tools become, I hope we keep passing that opportunity on.

Free to use, and free to carry forward.