(forw) Re: [License-discuss] code hosting

I may re-host a mirror of Loïc Dachary's 2001 article warning about
SourceForge seeming to go proprietary and the sponsoring corporation
being seemingly dishonest about it, because it's an important lesson in
one time-honoured way businesses can and do con the open source / free
software community.

Immediately after Dachary's warning, VA Software Corporation trotted out
Patrick McGovern (SourceForge.net Director) to speak with forked tongue
about (loosely paraphrased from memory) how Dachary's concerns were mistaken
and that VA was totally devoted to keep SourceForge a real open source
project for the foreseeable future, tra la.  I found a reference to that
dog-and-pony show in the French language, and can probably find an
English-language one if I look around a bit.  Anyway, it was all
bullshit, intended to delay and confuse the community's response to just
fork the damned thing, already.  And, point is, it worked.


----- Forwarded message from Rick Moen <[email protected]> -----

Date: Wed, 12 Jun 2019 14:13:08 -0700
From: Rick Moen <[email protected]>
To: Thorsten Glaser <[email protected]>
Subject: Re: [License-discuss] code hosting
Organization: If you lived here, you'd be $HOME already.

[As you saw, this was quite rightly declared off-topic, 
and I'd already exited, but appreciate your comments anyway, 
hence am sending you off-forum thanks.]

> Yes, and I’d also not touch Ruby. I’ve not mentioned this much
> because it was growing OT (hence the Subject change).

Personally, I see no problem at all with Ruby the scripting language,
and find it pleasingly constructed, more likeable than Python and
suitable for many of the same purposes.  Obviously this is a personal
thing -- but the main point is that the merits of Ruby on Rails are
distinct from that of Ruby, those living in entirely different
categories.

Doing Operations work, I often run up against Ruby as the underlying
scripting tool in the Puppet and Chef configuration management tools,
and... it's OK.  It's modern (dynamic typing, OO to the core unlike
Python), has a consistent, C-like syntax, is easy to read, borrows 
ideas from Lisp, Perl, Ada, Smalltalk, and Eiffel, and generally IMO 
is sanely designed and generally useful.

> >better-designed alternatives such as Gogs and Gitea.
> 
> *cough* sshd and gitweb, and a post-receive hook for mails…

*shrug*  sshd to mediate access is difficult to ignore in the current
world, IMO.  gitweb is not _too_ monstrous.  ISTR it's a Perl thing by
Kay Sievers and is considered integral to the git distribution.  The
notion of a git repo needing a Web interface at all is of course absurd,
and for a long time I wondered 'Dudes, why not just use git?'

Git by itself of course has no infrastructure for managing authorisation 
and access controls, so unless you intend to have all of your developers
get to the repo via ssh keypairs or something equivalent, you need a
layer to handle that.

_Without_ a Web layer, a perfeclty fine, right-sized solution exists
called Gitolite (https://gitolite.com/gitolite/).  I _think_ its
development was inspired directly by the infamous kernel.org security
compromise, which was never fully explained to the public but probably 
(my guess) resulted from a Linux kernel developer's ssh keypair getting
compromised elsewhere, an intruder entering to kernel.org shell using
the stolen credential, and then that intruder cracking root from the
inside.  Careful forensics were done while the site was offline, and
afterwards all Linux kernel developers had to use Gitolite-mediated
access for their contributions -- it being designed to give developers
adequate security access with no possibility of access to shell.

But places like OSI would not regard Gitolite, as good (IMO) as it is, 
as adequate because it doesn't speak to the Web.  Which is why gitweb
and things built atop it (everything from GitHub to Gitea/Gogs -- see
gitweb page for a partial list) sprang up and will remain popular no
matter how many times people like you and me say 'The Web is not the
friggin' Internet!'

> Open Core has its own problems: often, the comments are stripped
> from what is published (which I really consider not OSS, even if
> it follows the letter of the licence), and even if not (and it’s
> proper OSS _software_) it’s not proper OSS _community_ because the
> company will reject patch submissions adding features to the “open
> core” version that reduces the “value added” of their commercial
> version.

One of the reasons I risked making myself unpopular again with OSI's
Board is that, from time to time, it's necessary to remind those lawyers
and software bureaucrats that 'open source' alone is a very low bar to
cross and does not by itself make something desirable.

I still think Discourse is at OSI what in American slang is called a
'done deal', something inevitable.  Some (most? all?) of the anger
exhibited against my critique seems to be exasperation at my calling
into doubt something already privately decided.  My guess, anyway.

I was disappointed in Luis Villa deflecting my Discourse and
GitHub/GitLab criticisms with a variety of fallacies, starting with
personal vilification, careless-at-best misinterpretations of everything
of substance I said, and also just summary dismissal.  He knows what
he's doing, and it's... disappointing.
 
> Their operations team consisted of the lead FusionForge developer (who
> freelances around and has been seen less and less in Debian, but his
> job was mainly the adjustments to the infrastructure) and
> one-and-a-half other persons who did all the maintenance. These were
> the driving powers behind the move… they considered Feodora’s thing
> “Pagure” then surprised everyone with the switch to Gitlab CE and
> “run” (for very low values thereof) that since.

Thank you for filling me in on that history.

As I mentioned, I was a VA Linux Systems employee when SourceForge as an
open source project was launched as, initially, an unofficial
side-project written to extend the 'Trove' software metadata system,
coded by the now-late Tim Purdue with a couple of colleagues including
Tony Guntharp.  (I was not in any way involved.)  Technically, all VA
Linux Systems wrote was some glue code and cron jobs, called something
like va-alexandria, and called 'alexandria' for short.  Everything else
was pre-existing best-of-breed outside software such as Mailman, CVS,
and a great deal more.

VA Linux Systems attempted a subterfuge to fool the open source
community into not realising it would be taking SourceForge (alexandria) 
proprietary.  One very intelligent outside observer, Loïc Dachary of FSF
Europe, wasn't fooled and called public attention in 2001 to the
implications of VA Linux Systems suddenly asking for assignment of
copyright and very suspicious disabling of some export functions:
https://web.archive.org/web/20011201022551/http://www.fsfeurope.org/news/article2001-10-20-01.en.html

As an employee, I could not ethically comment about this outside the
firm, but was very glad Dachary got the word out -- but the immediate
result was that VA Linux Systems's disinformation created deliberate 
delay and confusion.  The firm promised that alexandria would continue
to be maintained as open source indefinitely, but that was an outright
lie.  The trap was finally fully sprung a couple of years later when
access to the alexandria code repo was suddenly and quietly withdrawn
and third parties (such as Debian, FSF with Savannah, and several
others) forked based on several old snapshots.  I kept wanting to say
'Dudes!  Stop waiting for more alexandria code drops, ignore that lying
corporation, get together and decide which snapshot to regard as
authoritative, and organise a unified outside effort.'  But I could not
ethically speak to that, while employed there, so I didn't.

This confused situation persisted until Purdue was dismissed from
employment (along with the other coders, as VA Linux Systems became VA
Software and then Sourceforge, Inc., and the firm attempted and failed
to outsource development to a big J2EE codemonkey shop in Tamil Nadu).
Purdue waited six months until some termination agreement (I'm not clear
on what) expired, and then released as 'GForge' the final alexandria
codebase that was truly open source within the firm, i.e., the day that 
public access was quietly withdrawn.  Finally, what I kept wanting to
urge the community to do existed.

GForge went mostly-proprietary eventually, so there was a further fork,
which is what is now called FusionForge.

However, the alexandria codebase was pretty much inherently awful
spaghetti code, as an automatic consequence of it being just messy glue
code and cron jobs, and certainly was nothing a sane software engineer
would set out to architect, and I have no doubt FusionForge is a mess
because of its heritage.  But the various SourceForge descendants were
always reasonably functional, and could scale well.

I actually hadn't heard of Pagure until now (not having much to do with
RedHat/Fedora/CentOS except when I'm paid to), so thanks for mentioning
that.  It looks like a from-scratch attempt to do SourceForge less
messily in Python -- not a bad idea at all.


----- End forwarded message -----

_______________________________________________
svlug mailing list
[email protected]
http://lists.svlug.org/lists/listinfo/svlug