Re: [boost] Re: Why Jam?

From: David B. Held (dheld_at_[hidden])
Date: 2002-02-23 13:33:29

----- Original Message -----
From: "Braden McDaniel" <braden_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, February 22, 2002 11:27 PM
Subject: Re: [boost] Re: Why Jam?

> On Fri, 2002-02-22 at 23:30, Chris Little wrote:
> [...]
> > Boost is an experiment in leading edge C++ design.  The goal isn't
> > necessarily to create a library that integrates well into your unix
centric
> > view of software development.  In fact there isn't a required set of
> > platforms that an implementor need to support.
>
> The success of this project will be measured to a large degree by the
> size of its user base--like most any other project. This is about making
> Boost usable. That's all.

Well, I'm not sure you understood what Chris said.  The project *isn't*
about how to produce a library with the broadest possible user base.  As
I understand it, the purpose is to create "prior use" cases for suggested
language modifications.  To that end, a sufficient number of people will
use Boost, easy or not, and help to establish how new idioms and concepts
work in the real world.  I would thus conclude that the success of this
project will be measured by what good and useful language features make
it into the next standard because of a demonstration of prior art.  That can
be accomplished without catering to the needs of every user (and seems
to have done so just fine until now).  I think it's just a nice side effect
that
people like me get to use really powerful libraries boost::function,
boost::bind,
and boost::smart_ptr, and if I see the best features of these libraries in
the next version of C++, I will feel that Boost has accomplished its goals,
as probably will the maintainers and authors.

> > If you want to use Boost in one of your projects then I think that it is
up
> > to you to provide integration for your users.  It is not as if Boost
makes
> > any guarantees about binary or source compatibility (although as a
> > community I would hope that we minimize the amount we break things
> > while evolve them) so any project you make will have to bound to a
> > particular Boost version anyways.
>
> This is par for the course for open source projects. It may be novel
> from your perspective; it is not from mine.

To this extent, I see Boost as "more Open-Source than Open-Source".
To put constraints on an Open-Source developer as to how many platforms
should be supported, and how other things like installation should be
handled really limits developers.  Some developers don't have every
target platform to test on and write workarounds for.  Some just don't
have the time to create a one-button-push install procedure.  If Boost
were a singular effort like Apache or MySQL, it would make a lot more
sense to provide things like sane install targets.  But Boost is much looser
than traditional monolithic OSS projects.  In this regard, many OSS
projects are more like closed-source software than Boost is.  Boost
provides raw libraries with raw power, no promises or guarantees.  It
is offered freely, by people who are very capable at producing some of
the best code possible.  To expect each library author to maintain his/her
library like it's a big team OSS project seems quite unfair to me.  It also
seems selfish to expect that pro-autoconf constraints are more important
than pro-Jam constraints.  As far as I can tell, this thread sounds like
a Porsche dealership giving away free cars, and people complaining
that the cars aren't driven to their doorstep.  It doesn't seem unreasonable
at all to me to meet them halfway.

> You say that like I was reluctant. That is a misrepresentation. When
> this thread started, it was not clear that an autotools build would be
> accepted into Boost even if it was offered. In fact, I think one could
> reasonably conclude that it would be rejected based on threads prior to
> this one. Fortunately, it now looks like an autotools build would be
> accepted. That's all I've ever wanted.

From what I observe, the "Boost process" is to *ask* whether a library
or tools submission would be useful or welcome first, instead of telling
people that they want and need it, and if they don't, they are closed-minded
pig-headed greedy proprietary jerks with their heads in the sand.

> It may be self-satisfying to characterize the autotools crowd as a bunch
> of complainers. But in doing so you ignore the "Let them eat Jam" policy
> that led to this thread.

And to be honest, I think it's entirely the prerogative of those offering
free
bread to offer a Jam-only version.  If you want your bread toasted or
pre-made into a sandwich, perhaps you should ask whether you are
grateful for the bread, or feel you are just entitled to it.

> That's changed, and so on this much we agree: Let's move on. I'm
> looking forward to seeing Timothy Shead's submission.

As am I.

Dave