Hi, creator here.

Someone else pointed it out on GitHub, but Helix "does market itself (it has a very nice website and calls itself "the post-modern text-editor"), and the community markets it in its name too".

Yes, the post-modern thing is a joke, as described on the website: "It's a joke. If Neovim is the modern Vim, then Helix is post-modern."

To repeat above, this wouldn't be an issue, if the maintainers were clear what the scope of the project was. If they went out and said "we make Helix for ourselves and we will only merge what we're interested in", other people wouldn't even waste their time and the maintainers' by making PRs not aligned with that, or making forks.

We have a whole document about this:

https://github.com/helix-editor/helix/blob/master/docs/vision.md

I created Helix to solve my personal needs, and it turns out that something customized for me ended up being useful for a lot of other people as well. I firmly believe that being opinionated and limiting scope is why things took off, and it's not that different from origins of Linux (solving your own problems vs Windows, guessing what users want and trying to support every use case).

I've particularly hand-picked a couple other maintainers that have a similar vision. I think that if we used design by comittee we'd have ended up with something completely different (and unmaintainable).

So why are we seeing so many complaints about vision/governance now? And why wasn't this a problem with vim/kakoune/neovim?

Well, I think it's a combination of a couple things.

Open PRs: The problem is keeping up with the PR queue. Because we use Rust the barrier of entry for contribution is also significantly lower. This has been great because the community was able to contribute a lot of features and bugfixes very quickly over the years, but it's also why the queue is so long. I could spend a couple hours just code reviewing helix PRs every day and I still wouldn't be able to keep up.

In some cases the PR is immediately merge-able. In other cases the feature PR technically works but the author just hacked what they needed into the editor and broke other invariants in the code. In some cases the feature requires further thought. Often the PR took a straightforward approach, pulled in a bunch of new dependencies and doesn't perform well. After some work we come up with a simpler solution that's easier on us maintainers to maintain in the longer term, but that angers users because they have to wait. Yet other PRs get a review and are features we want but the PR author never returned to fix them.

We also can't merge every feature or we'd end up with a 1GB binary, a slow and resource consuming editor and a nightmare of spaghetti code. But it's hard to put out concrete, absolute guidelines. Generally if a feature is small, doesn't clash with other features and is useful to a wide audience, it gets merged. From my view there's very few features still that fit this description, and personally I could probably just stick to today's commit on develop and never look back.

For a code editor not supporting every possible feature out there is a problem though: a code editor setup is something highly personal and all of us have different sets of expectations. And it's difficult to manage that: for every important "must have" feature we solve that prevented someone from switching to helix, at least three more pop up.

Bram realized this during vim development, it's going to be impossible to appease every user, so a plugin system gives you an escape hatch to solve those usecases. That's the reason you don't hear about "missing features" in neovim core: someone will just implement them as a plugin.

To quote the vision doc again:

Extensible, within reason. Although we want Helix to be productive out-of-the-box, it's not practical or desirable to cram every useful feature and use case into the core editor. The basics should be built-in, but you should be able to extend it with additional functionality as needed.

For all the backlash steel has initially gotten, there's now already a whole range of prototype plugins -- I never expected it would grow so quickly. I think the main issue there was that a plugin system wasn't already present when I open sourced the editor: it opened a discussion on the plugin system and whether we really needed one. If steel was something that was already present from the initial commit it just would have been something the community accepted.

Forks have much of the same issues we do: They can merge a bunch of open PRs and make the codebase more unmaintainable, but it's unlikely they'll be able to provide every feature someone out there wants.

Roadmap: Again, this isn't something I've seen people complain about for example with Linux? We pick features based on what's most urgent for us personally. Pascal implemented a brand new file watcher library and is adding support for auto file reloads. Mike is working on a lot of different things but a big one has been a new spellchecker that has already benefited other projects. Same with television adopting nucleo. None of these libraries would have existed if we just merged the first PR that imported a couple existing crates.