On Friday, 9 January 2015 at 18:01:50 UTC, anonymous wrote:
On Friday, 9 January 2015 at 06:43:01 UTC, Joakim wrote:
On Tuesday, 6 January 2015 at 22:37:40 UTC, anonymous wrote:
[...]
As far as I know there are companies that employ developers
to work on open source software, with their patches
open-sourced immediately. I'm assuming the employer can
direct where exactly the effort goes. That's essentially it,
no?
A few companies may do that, but he referred to paying for
fixes you want right away but getting patches other companies
paid for for free. I don't know of any commercial support
model where that happens.
When two companies hire two different guys to work on the same
OSS project, each company pays for the patches of their guy,
while getting the patches of the other guy for free.
We were talking about commercial support models, so presumably he
was talking about a single support company that will both fix
your problem on demand for money and give you other such fixes
for free. I pointed out that they usually use support
subscriptions, where it's more accurate to say that you're paying
for all those other fixes too, just less than the ones you
directly asked for.
As for outside companies, as long as they release their fixes,
sure, you get them. But that's also true in the hybrid model
I've laid out, after the funding/time limit has passed, ie you'll
eventually get outside fixes you didn't pay for.
For example, I just googled "paid linux developers" and came
across an article [1] that states:
"Within that field Red Hat topped that chart with 12% followed
by Inte with 8% IBM and Novell with 6% each and Oracle 3%.
Despite the clear commercial rivalry between those players
central kernel development worked well Corbet noted."
Now it might be that they hold back patches for some time to
gain an advantage over the competition. But it's my uneducated
impression that they don't.
These consulting companies likely don't hold back many patches,
because the GPL requires that they give them to at least their
customers who deploy the software. But the companies deploying
the software in their own offices can hold back the patches.
[...]
Yes, _anything_ you pay for is a competitive advantage for you.
He seems to think only the direct features of your product are
your competitive advantage, but indirect costs like this also
affect the price and overall quality of your product, at least
relative to other products in the market, which are just as
important.
[...]
Businesses generally don't sink money into stuff that provides
them no competitive advantage. Therefore, the
counter-proposal is pure fantasy.
I would have guessed that business is happy to invest when the
return is right. Business wouldn't say no to making more money
just because someone else makes more money, too, would they? Of
course, strategic considerations have to be factored in there.
Like harming or benefitting a competitor. But also brand image
and whatever else.
You maximize your return by keeping the patches to yourself, at
least for a while. So yes, they may invest, but they may not
release right away.
[...]
The win for the customer is that they're getting a patch that
would not otherwise exist, not sure what's more clear than
that.
Sure, but this is all about how it's a bigger win than
open-sourcing the patch right away.
I'm just countering your claim that there is no win for the
customer in the hybrid model. It is also a bigger win than
open-sourcing right away.
[...]
I'm not sure exactly what you by mean by competitors buying
patches collectively. If you mean that all the companies pool
together and fund OSS development, how do you keep some
outlier from not contributing any money, using the resulting
OSS code, then undercutting you on price?
I assumed that the competitors know each other. That would make
it an all-or-none deal. And the obvious choice would be to
split the cost. When there may be serious unkown competition,
it becomes unfeasible, I guess.
Paid closed-source patches are simply another way of splitting
the cost between customers, where you make sure there are no
holdouts, because they don't get the patch unless they pay.
[...]
I don't know what the minor/occasional contributors think, so
who knows how they'd react to such a move, but D could well
afford to lose them if it gets several paid devs and some new
OSS contributors from the resulting larger D community in
return. :) The cost-benefit on that is a no-brainer, you have
to go paid.
The 'if' is the thing. Lose too many volunteers while
attracting not enough business and whoops you're going in the
wrong direction.
If they're minor/occasional contributors as you said, they won't
make much of a difference.
Also, personally I like volunteerism. But that's just me.
D has gotten very far as a volunteer project. But it has
essentially no uptake in medium to large commercial deployments,
just Sociomantic AFAIK, and they're running an old version, D1,
with significant modifications. Volunteers are not going to
produce a compiler with the polish to get into such places.
Now, there's nothing wrong with D staying a hobby language with
dozens of contributors and tens of thousands of users for the
next decade. But Andrei has talked about taking it to the next
level with commercial support. This is a way to get there,
likely the best way.
[...]
Since no core dev has expressed any interest in this thread,
that is the likely route. But even if they did, no other
member of the D community has any claim on their time. Their
contributions to D are donations of their time. For a member
of the D community to say they can't also sell some of their
D-related time to willing buyers is utter nonsense.
Again, it's not that anyone has any right to make demands of
anyone. Of course, anyone can start their own closed fork of D
[2]. But, depending on a thousand details, if the right/wrong
people do it, it may hurt the popularity of D.
There aren't right or wrong people to do it, the people who think
so are just being silly. They simply feel entitled to the
regular OSS devs' work because those devs have been generous
enough to give it away so far, which is a horrible, delusional
mentality. If it became less popular with them, who cares.
There are a lot more people who would use D if it had commercial
support and was more polished.
Similarly, if Walter proclaimed that D was a big mistake and
that he favours Go or Rust or whatever now, no one has any
right to demand he keeps working on D, but it would probably be
a bad move for the popularity of D.
But the two are completely different situations: in the first,
he's still working on D, just providing an enhanced paid version
too, while in the second, he's saying it's not as good as some
other language.
It is understandable why the second situation would hurt D, but
not at all in the first.
