Commitment

Yesterday I read solderpunk's article about a new protocol called Mercury, an even simpler Gemini. No TLS, no client certificates, obligatory UTF-8, and no more proposed features. It seems to be merely a thought experiment, but it's likely to be implemented eventually, considering how simple it is.

The Mercury Protocol

nyptu wrote on his "flight log" that he sees no meaningful difference between Mercury and Gopher. There is no reason for Mercury to exist in a world where Gopher exists and thrives in its own niche.

nyptu's flight log

I agree with nyptu here, but I'm more interested in solderpunk's state of mind when he suggests Mercury.

Gemini's mission is to be a simple Internet protocol. Somewhere between Gopher and the Web in terms of complexity. It has become popular recently, growing into a network of over a thousand capsules so far. Countless individuals have experimented with it after tiring of the Web's bloat. It's simplicity is alluring to those of us who idealize minimalism.

Now that Gemini has taken off, its original designer is wary of where it's heading, and is considering launching an alternative. This seems to be a pattern in software design. The project may go in a direction the original designer doesn't like, and then they decide to take the development in a different direction, forking it.

I felt similarly with the Heb12 Bible app. When I wrote the first version, I was excited and designed the main application in a few weeks, and continuously improved it for months. Eventually, however, I second-guessed certain decisions I made, including using Electron, and decided to rewrite it. Whether or not that was a good decision, it's been two years since I decided to rewrite it, and it is still not complete.

Meanwhile, my friend Daniel has been making incredible progress. When he first joined I was thrilled. He had a passion for the project that surpassed my own. I merely started the project. It changed Daniel's life.

But like any group of people, we disagreed on some issues. Minor things like programming style and bigger things such as which programming languages to use to write the app divided us. I became discouraged. I didn't want to hurt Daniel's feelings, but I also stopped being passionate about the project. I lost my sense of direction and development slowed almost to a halt.

I considered doing yet another rewrite on my own, leaving Heb12 and Daniel to start another project. I justified it in several ways, telling myself disingenuously that "Heb12 isn't a good name" and "this project will have different goals somehow". I began writing Bible-related libraries on my own, trying to avoid Daniel's scrutiny. I even rewrote code he had made, again justifying it by thinking mine had a different purpose.

When other people get involved in a project, having vision becomes complicated. Instead of solely having one person's goals direct it, other people also voice their own opinions. From my perspective, Heb12 stalled because I prioritized my own limited ideas over commitment to the project and our shared goals.

Starting projects is easy. Following them through for years is difficult. I had so many ideas when it came to Heb12 that it paralyzed me. I kept wanting to tinker but rarely wrote anything useful. If something wasn't perfect I became discouraged and wanted to scrap it and start over.

The community has designed all kinds of wonderful software for Gemini any many people have even replaced their websites with Gemini capsules. Many of us are committed to its success.

Nothing is perfect, and that includes Gemini. I'm sure it has blatant flaws. It certainly could be designed better. Anything could be. But Gemini fits its niche right where it is, and people have grabbed hold of it. As long as we share the same vision of simplicity, it can fulfill its goal. Second-guessing our choices will ultimately limit our ability to go further.

As for Heb12, I'm going to get back to work.