Re: [Caml-list] GODI is shutting down

[Jun Furuse <jun.furuse@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

Hi Fabrice,

Have you discussed your idea of OPAM with Gerd or GODI community before
starting the project? Was there no way of working together, to improve
GODI, or invite Gerd to OPAM development?

Best regards,
Jun
 On Jul 24, 2013 3:04 PM, "Fabrice Le Fessant" <Fabrice.Le_fessant@inria.fr>
wrote:

> 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
>
>

[-- Attachment #2: Type: text/html, Size: 3873 bytes --]