Re: R: Consortium Caml

[Xavier Leroy <Xavier.Leroy@inria.fr>]

There has been lots of discussions about the Caml consortium on this
list, and some of the comments make me think that the goals of the
consortium are perhaps not clear enough.  So, here is my personal view
on it.

First, the consortium is (at least initially) targeted towards large
corporations.  This explains the choice of a relatively high
membership fee.  One of the first questions that potential industrial
users of Caml ask is: "who else is using it?".  What they really mean,
though, is: "what other big companies use it?  Does my competitors use
it?".  That is, they don't really care about "small" users -- even if
these are numerous and talented and contribute a lot to the OCaml
development.  They want to hear about big, respectable companies that
they already know.  And if one of their competitors is already on the
list, this gives even more incentive for them to join :-)

Second, the membership fee is not just a donation.  In particular, it
can be a way to share the cost of specific developments with other
consortium members.  Consider the following situation.  Company X
wants to use Caml, and needs some tools, libraries, documentation or
support that INRIA currently doesn't provide, or can't provide at all,
or doesn't provide well.  For instance: a CORBA binding.

Without the consortium, the choices of company X are:
- Do the development in-house.  In general, X doesn't have the manpower
  or the competences to do this.  And managers tend to dislike 
  such in-house developments ("not our core business!").
- Contract with a software house to do the development.  (This has
  happened before in the case of the CORBA binding.)  But software
  houses charge a lot, and generally do not have the Caml competences
  required.
- Give up on Caml.  Happens quite often, I'm afraid :-)

With the consortium, there is one more possibility:
- Pay the membership fee and use their voice in the consortium to demand
  that the consortium does the development.

Of course, if company X is the only consortium member asking for this
development, its demand will not be considered unless company X gives
enough money to allow the consortium to hire someone to do the
development.  Still, this can be cheaper and more effective than
contracting with a software house: INRIA effectively charges for labor
(through the membership fees), but donates the office space,
administrative staff support, and most importantly the training of the
developer thus hired.

Things become a lot more interesting if several consortium members ask
for the same feature.  Then, the costs are not only reduced as
described above, but also divided by the number of interested
members.  Continuing the CORBA example, I know of about three
companies that would need a CORBA binding.  If they team up in the
consortium, and pay 10K euro each, they can get what they need.

So, it's a win-win situation (please pardon my PHB speak): members get
what they need at a reduced cost, and the Caml community benefits from
a new development that is publically released and usable by all
(which is generally not the case of in-house or contracted
developments).

You may ask: what guarantee does company X have that its money (the
membership fee) will be used to answer its needs?  How can it be sure
that the money will not be spent instead on, say, buying me the Jaguar
coupé that I so richly deserve?  One answer is that INRIA's spendings are
severely restricted by the French public service laws, which exclude
among other things buying cars for researchers.  (Guess I'll have to
keep my 12-year old Renault, then.)

The real answer is that the consortium wants its members to come back
the year after.  An important goal of the yearly meetings with members
is to account for how their money is spent.  A member that is not
happy with the utilization of its money will simply "vote with its
feet" and not pay the year after.  Since the consortium wants to stay,
and keep the developer(s) it hired as long as possible (so as to
minimize training effort and improve the quality of developments), it
is its interest to satisfy the needs of the members as much as
possible.

I really believe this can work well.  The only thing is that in order
to start, we need enough initial members that contribute enough
membership fees to cover the cost of hiring one good developer.
Let's hope that this "critical mass" will be achieved.

- Xavier Leroy