AW: [Caml-list] GODI is shutting down

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Let me answer to this message, because it is again fact-based, and not  
full of unproven or poor-quality claims.

I hope the reader can now understand that OPAM is set up as competing  
project from the beginning. Basically, three organizations joined to  
create a new software. The discussion about the design wasn't public. I  
was excluded from the beginning - and don't understand why, since I  
made an offer for cooperation when I first heard from Ocamlpro's plans  
(not about OPAM in particular, but other stuff, but I suggested to  
cooperate in package manager questions). I never got a response to my  
initiative. Instead, there was later questionable behavior from  
Ocamlpro, namely that they copied (at least parts of) GODI packages,  
without having asked for permission. (In particular, there was evidence  
that they copied the package description texts.) This might be legal,  
but the reader will understand that this is unfriendly, and  
unneccessarily aggressive. At that point it was clear that they are  
trying to push GODI aside, even with questionable means.

In the past days I made the experience that OPAM advocates never answer  
to any of my objections. When I said "GODI has feature xy, why doesn't  
OPAM has this too?" the only response is something like "OPAM has this  
great Github-based workflow" (the most harmless variant). Discussion  
impossible.

Fabrice claims that OPAM has GODI's strengths and tries to avoid its  
weaknesses. I'd say this is just a personal view, because there was  
never a public discussion (and Fabrice would probably be surprised what  
I consider as GODI's strengths). I know very well where GODI's  
weaknesses are, but I'm sure a public discussion would reveal that  
there are a number of useful features that are currently missing in  
OPAM, and where "we use Github" is no excuse. It would be very helpful  
if the OPAM developers would a bit more self-critical, and did not  
continuously claim that their software is superior (well, you know  
Github, and dose3).

Let me only add one fundamental point where I think OPAM just takes  
just one direction, and that it is worth a discussion never done. One  
of the principles seems to be to make it as easy and comfortable as  
possible to package up libraries. At the first glance a good thing, but  
if you look deeper you'll see that this principle collides with other  
ideas, and at least a modification of the principle is worth a thought.  
There is the QA question, at least for the main repository (NB. as the  
bad word of "dictator" was mentioned - yes, for the main repository  
there is a dictator, both in OPAM and GODI, but belive me there is  
enough anti-power). There are features in package management that are a  
hassle for the packager, like clean deinstallation, or how well a  
library is integrated into the OS. So far I've the impression OPAM just  
ignores this, in the hope to attract as many packagers as possible. It  
would be a bad deal if packager's interests always won over user's  
interests.

A final remark to Fabrice's side story. Of course, it is normal that  
software is suddenly no popular anymore, and users switch to a  
different product. The user decides, after all, and developers  
shouldn't take this personally. The software market is a jungle.  
Nevertheless, this doesn't mean we shouldn't try to be civilized.  
Often, there is an alternative (e.g. cooperation), and most often the  
civilized way leads to better results (e.g. imagine mplayer would use  
your assembly routines).

Gerd

Am 24.07.2013 09:03:46 schrieb(en) Fabrice Le Fessant:
> On Wed, Jul 24, 2013 at 3:55 AM, Francois Berenger  
> <berenger@riken.jp>wrote:
> 
> > On 07/23/2013 06:07 PM, Adrien Nader wrote:
> >
> >> Hi,
> >>
> > > [...]
> >
> >  To be honest, I've never understood why opam was "started".
> >>
> >
> > Contracted development, I guess.
> 
> 
> Yes, mostly. OCamlPro have had a contract with Jane Street since its
> creation, on improving the OCaml environment, to the benefits of both  
> Jane
> Street and the whole OCaml community. The creation of a new package  
> manager
> was identified very early as a strategic element, to improve the  
> usability
> of OCaml, and increase its popularity. Thus, we started working on  
> Opam, in
> a collaboration between OCamlPro and INRIA (within the DORM european
> project), with deep inputs from the Mancoosi team at University Paris
> 7/IRILL (working at improving Debian package management), and later  
> joined
> by OCamllabs as soon as it was created.
> 
> Of course, Opam would not have been the same without GODI: in its  
> design,
> Opam directly benefited from the experience of GODI, as we tried to  
> keep
> GODI's strengths and to find better alternatives to avoid its  
> weaknesses.
> We also studied some other package managers, for OCaml (odb, yypkg,  
> etc.)
> and for other languages/systems (Cabal, CPAN, ArchLinux, etc.).  
> Finally, we
> made sure we would be able to easily port GODI's packages to Opam, as  
> the
> number of available packages from the beginning is an important  
> criteria
> for adoption of a package management tool by end users.
> 
> Clearly, both GODI and Opam are technically challenging software, but  
> they
> are not focusing on solving the same technical challenges (as  
> explained by
> Thomas), although the functionalities they provide are globally  
> similar.
> 
> As a side story, 15 years ago, I wrote one of the first open-source  
> video
> players for Divx files on Linux, in C++ with optimized MMX/SSE  
> assembly
> routines for zooming and so on. I was particularly proud of it, as it  
> was a
> domain in which I had little experience (but great interest ;-) ). I  
> got a
> few hundred users, when mplayer was released and all my users  
> progressively
> switched to it. Mplayer had support for some more video formats (but
> nothing I could not implement), and some of my assembly routines were  
> much
> more efficient. Nonetheless, since then, I have been a happy user of
> mplayer, and it is now much better technically than whatever I could  
> have
> done with my own player. This is typical of the software world, older
> projects are superseded by new projects, not always better on all  
> technical
> grounds, but providing a different user experience or pushed by a  
> larger
> team of developers.
> 
> --Fabrice
> 
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs



-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------