On Sat, Aug 26, 2023, 21:15 Philip Kaludercic <philipk@posteo.net> wrote:

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 26 Aug 2023 21:52:31 +0300
>> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
>> manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 25/08/2023 08:42, Eli Zaretskii wrote:
>> > IME, the development model of Emacs is an important reason why Emacs
>> > is still alive and kicking almost 40 years since it was first
>> > developed. And important major modes in Emacs are alive and kicking
>> > with it. So inclusion in Emacs and the pains of adjusting to a
>> > different development model are justified if one wants the major mode
>> > to remain alive for many years to come. Something to think about, I
>> > guess.
>>
>> Or the longevity stems from other reasons (e.g. good fundamental ideas,
>> unique proposition, being part of the original GNU system, ...), and the
>> development process is the reason the current user base is a fraction of
>> even Vim's (not to mention popular commercial offerings).
>>
>> Just an alternative POV to consider. In truth, could be a little of both.
>
> Mine wasn't a POV, it was an observation based on many years of
> watching the development and being part of it.

Correct me if I am wrong: This seems to be related to the fact that the
GitHub-model (thought it probably precedes it) of development has
motivated more and more individuals to maintain packages, instead of
organisations like GNU, Apache, etc. Or at least I understand that if
there is a collective effort behind maintaining the components of a
system, contributors can come and go without a package being abandoned
-- this is especially true for Emacs due to the extensive
introspectability. But it appears this reaches a limit, if a component
is too complex (CEDET was mentioned as one example, and if João were to
suddenly loose interest in contributing to Emacs, something similar
might happen to Eglot as well).

I don't know if you've ever compared the source of both packages,

but in terms of complexity Eglot pales in comparison to CEDET

This is by design, of course. Also, many moons ago, circa Emacs 22,

I actually tried to get CEDET working for a full C++ dev environment

in a company setting. I went through a lot of its code doing changes

(never published). I was a different programmer but I think I

would still find it just as impenetrable today.

Things are much better -- radically better -- these days. Not

thanks to Eglot but thanks primarily to LSP and the continued

quality work on half-decent protocols for connecting it to our

UI. Things like like xref, project, eldoc, flymake, company,

etc.

I'm a bit perplexed why you picked me as the star of "what if

he were to disappear?" but I guess I'm as good a candidate as

Michael, Lars, Dmitry or so many others.

So let me then offer my 2c on what is fast becoming the customary

yearly round of "whither Emacs?". Whenever GitHub looks to be the

essential catalyst of vibrant and effective software, look again.

The reason why so many projects looks like be they're going a million

km an hour is because they are, and they're accumulating loads of

bloat and technical debt in under-reviewed design decisions just

because it is so easy to press a green button to merge something.

You may as well have ChatGPT at the helm.

When they aren't, it's because a small group of devs is actively

curating and protecting the project, or because GitHub in itself

doesn't bring about any game-changing dynamic, such as happened with

SLIME which -- much like CL itself -- was half-moribund ca 2012 when

I helped move it to GitHub (with similar illusions to many others about

its redemptive power) and is half-moribund today (which is another word

for "reasonably stable" in the end).

So the lure of the "GitHub-model" is deceptive. More likely some devs of

some successful projects there are just sticking to it because they happen

to already know it very well and resist changing. Just like many devs

in "our" camp. More likely those "GitHub model" devs just don't dig

the vibe around these parts that much -- perfectly legitimate -- but are

a bit afraid to say so, so they say it's the CA requirement and the

patches model.

After all, this mailing list, for all the talk of obsolete mails etc,

is very heavily participated and even more heavily read. Just the fact

of having one's work scrutinized in such a big forum is not to everyone's

liking. And that's perfectly legitimate, too. Developing a package

outside Emacs is a liberating experience by comparison. Inside, there

is a completely new set of concerns, completely independent of the forge

you use. The format of manuals, coding style, commands you can

and cannot add, even the upgrade options you offer to your user base

are affected. As I've recently learned, moving a package from

the outside to the inside is a bit like getting married: you better

be prepared to give some things up and fight actively for others.

You have to love Emacs very much to make it work ;-)

In my personal case I find no significant difference in working with

either model. I find certain GitHub discussions and issue threads

just as pleasant or toxic as the things I find here. I find email

reviews of patches no more complicated than those sophisticated

boxes. Trivial patches to typos and stuff are indeed a little

harder to apply here compared with the the big green button. But

then trivial patches aren't the things moving a project

forward anyway. I could switch to SourceHut, of course, or anything

-- including GitHub. It won't make that big of a difference I think.

João