Re: [boost] [gsoc]

Subject: Re: [boost] [gsoc]
From: Robert Ramey (ramey_at_[hidden])
Date: 2012-03-25 14:42:31

Paul A. Bristow wrote:
> I think one area where we are failing is to get them really finished
> - and reviewed.  This is partly
> because it is difficult (nay impossible) to stop people biting off
> more than they can chew in the
> really very limited time available.

Indeed this is a "problem". Chalk it up to youthful exuberance.

> It might be better to use GSoC
> to finished existing projects,
> especially those that have been reviewed and accepted but need final
> polishing, testing and
> documenting? (The latter might well be done by someone who didn't
> write the original stuff - and
> thus 'knows too much').  This obviously needs the active support of
> the original author, but if he
> doesn't have time, then this should be welcome.

This would be useful, but it's not going to happen.

warning: tl;dr

Any software projects goes through phases:

I.  an idea - very fun and exciting and anyone can (and does) come
up with ideas. 99% are not good ideas for one reason or another.
It's fun to promote your idea though and suck other's into the
discussion.

II.  a prototype/proof of concept.  This often is done fairly
rapidly - it's still fun.  Usually it doesn't include more than one
test/use case, no documentation.  Essentially a toy.  This
is where most academic projects end.

III.  A first edition - ready for boost review.  This is
more than II above.  Getting to this point requires a lot of work.
And it's not really "fun" anymore.  One can still be motivated
by the accomplishment of getting something accepted by
a well respected peer group.  Still has a lot of loose ends,
documentation isn't all there, etc. etc.

IV. Working boost version. A HUGE amount of work to do
to fill in all the detail missing in stage III.  This includes extensive
tests and documentation and making the damn thing work on
all the test platforms.  At this stage it's discovered that the library
raises a bunch of new questions as to implementation, concept,
etc, etc.  The hurdle is only overcome by those who are almost
pathologically stubborn probably due to some other underlying
psycological issues.  This is not fun at all - it's like being on a
treadmill for 6 months.  And it's lonely too. It's not really "fun".

V. Maintainence.  If the library is successful - that is people actually
start to use it widely, bug/enhancement reports will filter in.  For the
library to be truely successful these things have to be addressed.
Each one means either fixing the library (fairly easy), ehancing the
library (maybe easy, maybe hard) and adding a test, or
ehancing the documentation.  These are all tedious tasks - but
mercifully, they are not too large.  Still, they are annoying and
not really fun at all. Only those who are anal retentive in their
quest for perfection (of course impossible to achive, but still
we have to try) can really find the time to do.

So it's not really realistic to try to give the latter phases to
SOC or other students.  It doesn't match their own goals
and they don't have the time to do anything but phases I & II.
Most people are too well adjusted pscologically to undertake
subsequent phases on a volunteer bases.

Based on this I really have reservations that GSOC is really
useful to boost.  Also, given Google's coding guidlines,
which explicitly proscribe most of boost and most of C++11,
I don't see how Google would find boost a match for them.

To me, a larger and more interesting is how does boost have
to change to maintain relevant 10 years from now.  C++
needs the libraries, but I don't see them coming from
anywhere.  And boost seems to be getting "bogged down".
Like many holy quests, it's seems in danger of becoming
a victim of it's own successes.

Robert Ramey