Re: Proposal for an Emacs User Survey

[Ergus <spacibba@aol.com>]

On Fri, Oct 16, 2020 at 09:33:12PM +0700, Marcel Ventosa wrote:
>On Fri, 16 Oct 2020 17:04:22 +0300
>Dmitry Gutov <dgutov@yandex.ru> wrote:
>
>
>From what I just read from Thibaut, a free software compatible solution
>to replace MELPA is underway. Refusing to draw attention to something is
>not "shutting our eyes".
>
Melpa will never die. Specially because it is a more open community; has
been around for long time and anyone can contribute almost
anonymously. It is the equivalent to the AUR in arch linux.

>
>I thought your argument was popularity, something that keeps coming up
>in these kinds of discussions. What was your argument?
>
Popularity, usability... there are many. Many packages in melpa are just
unique and has a lot of work invested on them that nobody is planning to
duplicate (ex: magit) 

>
>We could turn this argument around and ask why the developers who
>maintain MELPA don't remove `2-3' packages that promote non-free
>software. What came first, the GNU Emacs or the MELPA?
>
Because this 1) don't improve free software alternatives in any way 2)
will force the user to use free software instead of giving them the
option to choose it 3) Because it will restrict melpa in a way opposed
to its intention... Basically if a user is concerned then

1) will not add melpa to emacs
2) will read every package licenses...

>
>Indeed. As I recall, RMS suggested open questions instead of multiple
>choice questions that "shape their behavior". With open questions, there
>is no need to mention MELPA at all in fact. With open questions, the
>insights that could be derived would be much more interesting.
>
>
>That's very good news if the issue has been settled.
>
>
>Why should Emacs development be guided by (external) survey results? I
>would think it should be guided, for the most part, by what the people
>putting their time into it want to create, within the principles of the
>philosophy of the project and its goals. Also, anyone can suggest
>changes and convince the maintainers that these changes are in the best
>interest of the project (and contribute the actual changes if they are
>accepted).
>
The main problem we have in emacs is the limited number of active
developers. Half of the time the problem is not to convince the
developers to do the work; but having someone to do it... So in that
scenario, all the work invested in melpa packages is something we are
not in conditions to reject; because those developers provide support
and packages that we don't have the man power to do.

>If they are not, Emacs makes it quite simple to implement changes for
>personal "improvements". I have written functions that serve me
>personally and change the behavior of Emacs to suit my needs. There are
>limits to what I can do, which could be pushed if I dedicated a greater
>effort to do so. How is that unfair?
>
>If I thought one of my changes could benefit the community at large, I
>would approach the maintainers and suggest it. If they disagreed with my
>view, I could publish the code and could still share it with anyone
>willing to run it.
>
Exactly... and you can share those changes freely in melpa instead of
keeping them to you if you don't have a copyright, the changes are small
or just someone in your team don't want to register a copyright for any
reason, your package is in an initial state or for very specific uses;
your boss does don't give you a disclaim for your code, or you just want
to share your changes with the hope that someone in the future improve
what you did or find your idea useful in a more informal way.

That's the freedom that many users find in melpa over elpa. (like AUR in
arch linux). Share what they did freely without compromise and probably
get improves and feedback from the community without asking who are you
or if you have a copyright document or feeling the responsibility to
maintain the package in the future.