Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)

Subject: Re: [boost] Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-01-01 19:50:49

On 1/1/2011 9:12 AM, Dean Michael Berris wrote:
> On Sat, Jan 1, 2011 at 9:50 PM, Edward Diener<eldiener_at_[hidden]>  wrote:
>> On 1/1/2011 4:20 AM, Dean Michael Berris wrote:
>>>
>>> Well, there's the rub.
>>>
>>> Take what I said in the context of collaborative development instead
>>> of the current way of getting libraries into Boost. My issue with the
>>> status quo is that the barrier to entry for a library (and thus a
>>> contributor) is really high especially because of this practice of not
>>> letting others pitch into the work that goes into writing a library.
>>>
> [snip example]
>>>
>>> This process is nothing like the status quo, and is actually a more
>>> encouraging model that allows people to get involved with minimal
>>> effort required.
>>
>> You can not fail to understand that your idea of collaborative development
>> of your own library is not everybody's way of working. Do not try to force
>> that idea on everybody else.
>>
>
> Right, so what is the other idea of collaborative development?
>
> Notice that in the example process I posted, there was the chance for
> me to actually say "no, I don't like this patch". Also, under the same
> example process you can also do the "status quo" process, just don't
> announce your library for inclusion for Boost until you feel it's
> ready and don't accept patches once you've done the announcement. That
> example process allows for the status quo process *and* a more
> collaborative process to happen.
>
> But what's happening at the moment is that people who *like* the
> collaborative process *aren't* supported explicitly by the current
> Boost process. This means what's happening is, the current Boost
> process is imposing upon me the way to develop a library that I want
> to develop and am already developing.
>
> Note that the goal is to lower the barrier to entry, in which the
> current process introduces a lot of (barriers).
>
> 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. 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.

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.

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.