Re: [Savannah-hackers-public] Savannah and the present

[Fabio Pesari]

Hello Assaf,

I won't address most points you made because I actually agree with some
of your factual considerations, so the only thing I will address is what
I perceive as a recurring theme (with which I disagree, but I respect
your point of view): "If it ain't broke, don't fix it".

On 02/05/2016 06:45 AM, Assaf Gordon wrote:
>
> I have a hunch that there is a 
> disconnect between what some (younger?) people consider 
> modern/easy/convenient practices and what veteran users prefer.

I too feel comfortable using version control via the command line and
sending patches as attachments, however since free software benefits
from a high number of contributors and many people (especially the
"Github generation") want nothing to do with those things, I think it
would not be a compromise to satisfy their needs, since they wouldn't
affect the veterans'.

So, a lack of "shiny things" can actually be a deterrent for the growth
of free software, and that's not good. It also makes the free software
movement look elitist and stuck in the 90s.

With that kind of reasoning, things like GNOME and KDE would have never
been possible, because the command-line and Emacs would be considered
"just fine", and GNU/Linux would have even less than the 2% market share
it currently has.

> There are some people in our community that would argue that 
> conceptually, 'pull-request' have nothing to do with web-based 
> interface:,
> you 'git clone' instead of web-based fork,
> do 'git send-email' instead of web-based pull-requests,
> merging patches then become 'git am',
> discussing them is done over mailing lists by email,
> syntax highlighting is done in a code editor,
> and web-based usage is kept to a bare minimum, often times 
> in a text-mode browser.
> For project which use debbugs.gnu.org, bug management is also done via 
> email (akin to Github's web-based 'issues').

Those are 6 steps, across separate programs (Git, a text editor and an
email client, unlike you do everything in Emacs, which is great but also
subject of many in-jokes and stereotypes about our community).

Meanwhile, Github requires clicking on two buttons, "Fork" and "Pull
request".

I don't see how that affects freedom (since both methods could be
accepted), so I think it's not a compromise and anything that can make a
thing more welcoming to newcomers should be welcomed.

What affects freedom is needing a Github account in order to contribute
to most free software projects, like it happens today.

Perhaps Savannah is not suited for the purpose of replacing Github, but
at the very least the FSF should sponsor sites like:

https://notabug.org/

which are based on free software and host exclusively free software
(unlike Github, which accepts proprietary programs).

> This also keeps Javascript requirements to minimum - which is another added 
> bonus for some.

Github does not require JavaScript and can be completely operated by a
free command line program that uses their API called "hub".

The free self-hosted replacements Gitlab and Gogs don't require
JavaScript either, and when they do it's just for aesthetic purposes and
the JS is libre.

> I do not necessarily think that rich web-based features are not needed, 
> but it's worth considering the fact that from the above POV, savannah 
> already offers all the needed features for the common development 
> workflow model. 

And ImageMagick offers many of the same features as GIMP, but good look
convincing Photoshop users to use that instead!

> Personal anecdote: I was somewhat surprise to realize that there is a 
> strong push-back to changes to Savannah's front webpage if they will 
> cause it to render incorrectly on text-mode browser. That's just one 
> example illustrating that there are more constrants at play here - it's 
> not just about making the web interface friendlier.

But the current webpage does not render well on mobile browsers, which
are way more common than text-mode ones, statistically speaking.

> Savannah uses loosely-knit collection of different projects:
> Mailing lists managed by with 'mailman',
> Web-viewing with both gitweb and cgit (and ViewVC for CVS/SVN),
> anonymous git access through git-server (and similarly, cvs,svn).
> Access-control using SSH using unix-based users/groups, then passed on 
> to git,hg,svn,cvs .
> Bug tracking using DebBugs ( http://debbugs.gnu.org/ ),
> Downloads using rsync,
> and the web-interface indeed uses old ugly PHP.

Both Gitweb and Cgit can use syntax highlighting, by the way. That would
be a good improvement already:

https://wiki.archlinux.org/index.php/Gitweb#Syntax_highlighting

https://wiki.archlinux.org/index.php/Cgit#Syntax_highlighting

> Donating money to the FSF will also greatly help:
>     https://my.fsf.org/donate

I think it would help if people could donate to further specific goals.

I think if people could raise a year's salary specifically to hire a web
designer to fix the many ugly GNU websites (Savannah, GNU.org, FSF.org),
they would gladly donate their money (I speak as a former GNU webmaster,
so I have some first-hand experience).

Right now it's difficult to donate money to an organization without
having any input on how they will spend it, and this can create
controversies at times (like Outreachy did for GNOME, even if it's a
good program).

It'd be better to direct it specifically at certain tasks, so that they
can be accomplished in a short time. Redesigns can't wait another year,
and at the same time they can't take funding away from important issue
such as legal battles, so I think they should be funded separately.

> Savannah's relevance is not how many projects it hosts or how many new 
> users it has, or even how easy-to-use it is.

But that's relevant to how the GNU Project is perceived, and Savannah is
part of it.

If it's perceived as something old and clunky, we can't expect people to
support it, and consequently, many people will not make their programs
part of the GNU project, which often means releasing them under
permissive licenses to satisfy the "open source" supporters who think
the GPL is "viral" and "restrictive" and they "wouldn't touch any GPL code".

I think the repo criteria page was a good idea, but it must be backed by
a solid effort by the GNU Project, otherwise it's just theory and the
free software movement is already accused of being overly theoretical,
so it's the last thing we need.