help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issues with emacs


From: Pascal J. Bourguignon
Subject: Re: Issues with emacs
Date: Sun, 24 Jun 2012 03:24:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)

Dan Espen <despen@verizon.net> writes:

> Tom <adatgyujto@gmail.com> writes:
>
>> Bastien <bzg <at> gnu.org> writes:
>>
>>> 
>>> The good news is that, whether Emacs users are a dying breed
>>> or not, the only remedy to this hypothetical issue is to have
>>> more Emacs developers.
>>> 
>>
>> But how to have more developers. I see 3 possibilites:
>>
>> 1. Motivate more users to be volunteer developers? Any idea how
>> to do that?
>>
>> 2. Attracting more users. Volunteer developers are some small
>> percent of the active user base, so if Emacs can be mode more
>> attractive to users then the bigger user base will bring more
>> volunteer developers too. The problem is in order to be more
>> attractive Emacs needs new features which other editors/IDEs have
>> and which make users to choose those editors/IDEs instead of
>> Emacs, and to implement those more competitive features Emacs
>> needs more developers.
>>
>> 3. Crowdfunding. If we don't have enough volunteer developers
>> then we need to motivate developers with something else. For
>> example, paying for their work. For this model to work there
>> should be some public exposure of this idea, so potential
>> developers know they can potentially make a living while
>> contributing to Emacs. This kind of public exposure could be done
>> by RMS who could mention this development model in every
>> interview he gives. He has the voice which can reach lots of
>> ears, including potential developer ears.

It'd be nice to have some reliable statistics, such as:

    - absolute number of users of emacs.

    - % of non-programmer users of emacs.

    - histogram of programming languages (or in general modes) edited in
      emacs.




> 4. Have a whole bunch of missing functionality.

:-)

But it looks like there could be some improvements indeed.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]