|
Boost : |
Subject: Re: [boost] [simd] Hardware support
From: Thijs (M.A.) van den Berg (thijs_at_[hidden])
Date: 2017-04-08 14:07:25
On 08 Apr 2017, at 15:55, Niall Douglas via Boost <boost_at_[hidden]> wrote:
>>> Down the line, I hope to have some of my Boost libraries come with an
>>> open source edition with acceptable performance and guarantees, and
>>> commercial editions with much superior performance and guarantees. I
>>> think this would be a healthy development for Boost, if not pushed into
>>> silliness.
>>
>> While I respect the will to commercialize people's work, I wouldn't want
>> Boost to become an advertisement platform. Authors coming with their
>> libraries to Boost should be committed to provide a fair and proper
>> support of their libraries (i.e. those versions of their libraries that
>> entered Boost). That includes adding features to their libraries that
>> have demand in the community and are also present in commercial versions
>> of their libraries.
>>
>> When that is not the case, I would rather prefer such libraries not be
>> accepted into Boost. They can still be opensource and offered as a trial
>> to the full product, but they should not be associated with Boost, IMO.
>
> I know what you mean.
>
> But consider this. Imagine I make a toy key-value store and hand it over
> to Boost. It works well enough for most people. I then invest twelve
> months full time work into a serious key-value store which has been
> exhaustively tested in many major storage designs for correctness,
> costing me at least $150,000 to develop.
>
> I think it's highly unreasonable to expect that serious key-value store,
> even if 100% API compatible but just faster and better in every way to
> the toy store, to be released as open source until the cost of
> developing it is recouped from commercial licences.
>
> After all, the toy edition is good enough. It works. It just will come
> with no guarantees that it won't eat your data, and it will probably be
> quite slow.
>
> Niall
I would be worried about you (in this hypothetical case) being able to reject improvements to the boost version. Boost libraries are not aiming to be "average, good enough" type of libraries, they aim higher. So suppose that someone want to improve the boost versions, because it is all sort of slow bits, would you accept those changes as a library maintainer? Or would you block them because it would ruin your commercial business ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk