I don't know whether he knows it, but I think ZeroVer being a satire does not affect the essay's point much. There are lots of projects that start with major version zero (0.y.z) for initial development but then for some reason stick with it for long periods. There are also lots of projects that go with calendar versioning.
This is pretty neat, my only real gripe (and I know it is inherited from pod) is that the formatting tags can make it a bit difficult to read compared to plain Markdown, especially in the middle of text.
For example the line in the online editor:
This I<is> a B<text>
I find a little difficult to read at a glance.
The list items are also a bit visually "noisy" with every item needing its own "=itemX".
Is the plan to stick to the existing pod style rigidly or is there any potential flexibility for the syntax in the future?
Yeah I get that markdown is included in its own block, was just thinking about the non-markdown syntax and really what the plan is in general - i.e. are you looking to keep pod6 compatibility or are you looking to use the overall style but maybe deviate from the some of the basic standards.
Ahh, yes, of course, there are no dogmas here, I think all options are possible.
After all, this is just the beginning of the journey I think for Podlite )
I'm on the team working on Pulsar, the community fork of Atom. You have no idea how much we hear "Atom is slow", "are you making it fast?" etc. I have honestly yet to work out exactly what is meant by it. Startup times, sure, you are never going to get Pulsar/Atom or VSCode to launch as fast as a terminal editor or a super lightweight native one but that isn't how I personally use that kind of editor - once it is open it stays open for a long time. Keystrokes, context menus, highlighting performance, I honestly don't see where this perceived slowness is.
I'm not saying it isn't valid criticism but I guess the way I work with an editor just isn't the same as others who experience this.
There is actually another project called NeoSurf (https://github.com/CobaltBSD/neosurf/) which is a fork of NetSurf with the stated goals of "various privacy-focused improvements and additions, and a revamped build system." as well as other improvements.
Re: GitHub alternatives, I've been looking at this for a while as I'm keen to not have everything centralised and Microsoft are hardly the most trustworthy...
There are some GithHub-alikes, the most obvious is GitLab which you can also host yourself but all (or at least some of) the extras you get for free with GitHub are behind payment walls.
My current favourite is Codeberg, it uses Forgejo underneath (which is a fork of Gitea itself a fork of Gogs - all of which you can self host). Codeberg is run by a non-profit and are very much aligned with my ideals. They are also slowly adding nice features like their Woodpecker CI.
One that is growing in popularity and is a little less "GitHub-y" is SourceHut (which also has Mercurial support).
The main issue is that GitHub has really cornered the market. They give so much out for free that is difficult for others to compete with and it has become the de-facto place to host your project. This can mean that hosting anywhere other than GitHub will limit discoverability and contributions from people if they don't want to make an account or work out how to deal with whatever forge you are using.
However one thing that is coming that may help alleviate some of that is forge federation which will allow you to interact with various forges from your "home" forge - which hopefully prevents the need to make an account to make PRs or raise issues.
Edit: I see your other comment now, what could a better GitHub be that supports a better-than-git VCS. Well there did used to be places to host Darcs projects like the Darcs Hub but I don't know if some of the newers ones like Pijul or Jujutsu have any forge support yet.
Edit2: Oh it seems Pijul has "The Nest" for hosting.
Good point, we might want to document that. Btw, I've called it "native backend" and "native forge" myself, but maybe those are not the best terms because there are many possible native backends/forges.
For example, our "Piper" backend at Google is a native backend in the sense that it stores all data in its own database. I think the most exciting thing about that backend is that it's cloud-based so users will be able to access each others' commits (e.g. `jj show <commit id from chat>`) without requiring a push.
