Boost logo

Boost :

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2011-01-02 09:29:30

On Sun, Jan 2, 2011 at 8:50 AM, Edward Diener <eldiener_at_[hidden]> wrote:
> On 1/1/2011 9:12 AM, Dean Michael Berris wrote:
>> I'm not about to impose anything on anybody -- I was under the
>> impression that decisions like these would be a community matter. In
>> that case, I don't see why I shouldn't try to ask everybody else to
>> change the way they do things because, well, the current process is
>> asking me to change the way *I* do things. ;)
> You still do not get it.

I think I do get your point, except that what I'm saying doesn't seem
to be making much sense -- or at least not conveying the fact that I
get your point. :D

I was actually agreeing with you when I said that the current process
will be supported by the "extended" version I'm proposing. ;)

> So here it is as plain as I can make it. As a
> developer potentially creating for Boost I am interested in creating
> libraries myself, documenting and testing them, then offering them to others
> to use and comment on. If I feel like the comments will improve the library,
> I will improve it. If others do not like the library they will not use it,
> or not want it to be part of Boost, or they will create their own library to
> do what I have done. I may work on a library with a very few other people if
> that suits me, but I feel absolutely no impetus to work in a collaborative
> environment with a group of people, each one of which can contribute to the
> library in their own way.

Sure, and the expanded process I'm proposing *doesn't* preclude this.

The current process actually prescribes what you're proposing which
isn't necessarily wrong, except IMO -- and the whole point of the
discussion really is -- it doesn't scale, which is the problem I
wanted to address.

You can go about doing exactly this what you describe in the expanded
process and it wouldn't be a problem. But if the expanded process also
accounted for *explicitly* another supported means for getting
libraries from the review queue to the main distribution -- to address
the scalability, continued maintenance, and lowered barrier to entry
for potential developers -- then I don't see why that would be a bad
thing. It's all a matter of tweaking the process to allow for a more
collaborative way of developing libraries, not saying that any other
way (the current way or the way you highlight) would be discouraged.

The irony of it is that that a more welcoming and collaborative
process also embraces a non-collaborative process as the degenerate
case. :)

> Shocking, isn't it. There are still a few souls like me that are not going
> to create software as a community effort of people, but individually as my
> own design and effort to do something as best as I can. That does not mean I
> would not ask or accept help from others or give help to others if I can.
> Nor does it mean that I am not appreciative of the knowledge of others and
> what they may have to tell me to improve my efforts. But it does mean that I
> have almost no interest in initially creating any piece of software as a
> community effort.

Not shocking at all, and I account for that in the process I describe.
The only difference between a more collaborative process and a process
that you describe is that: in your case, you just don't put the same
premium on the collaborative aspect. Your community can be a community
of 1. ;)

> With all that said my view of community effort is much less harsh than it
> may seem. Of course developers should be free if they have the desire to
> contribute their effort to a library which already exists, as well as work
> on a library initially together if they like. But you should stop
> proselytizing for this as the end-all and be-all of all software development
> in Boost, as if everything done must be some community of programmers in
> some sort of collaborative effort.

Hmmm... I don't think I should stop "proselytizing" mainly because the
point of starting the discussion is so that I hope to at least be able
to convince people that a different way might make sense for Boost. I
didn't say it was the end-all and be-all, I was mainly putting out
ideas for how to lower the barrier to entry for potential

If I don't convince you, then that's alright by me. Although I say
again, what you describe would be perfectly fine in the process I was
describing a few emails ago. Now if others -- like me -- would like to
do it in a more collaborative manner than how you describe, I don't
see why the Boost policy or guidelines shouldn't explicitly allow or
at least encourage that as a means to scale the
development/maintenance/evolution effort to ensure that Boost keeps
going as an open source project that people want to contribute too.


Dean Michael Berris

Boost list run by bdawes at, gregod at, cpdaniel at, john at