1 |
On 12/17/2016 11:45 PM, Tom H wrote: |
2 |
> On Sat, Dec 17, 2016 at 4:36 AM, Daniel Campbell <zlg@g.o> wrote: |
3 |
>> On 12/17/2016 12:53 AM, Neil Bothwick wrote: |
4 |
>>> On Sat, 17 Dec 2016 00:55:21 -0500, Walter Dnes wrote: |
5 |
>>>> |
6 |
>>>> Again, the average home user is being jerked around for |
7 |
>>>> a corporate agenda. |
8 |
>>> |
9 |
>>> Yes, it is disgusting that developers add the options desired by those |
10 |
>>> that pay their wages while completely ignoring the users that give them |
11 |
>>> nothing! It's almost like they are scratching their employer's itch while |
12 |
>>> ignoring yours. |
13 |
>> |
14 |
>> I get where you're coming from, but Walter's talking about a real |
15 |
>> concern when it comes to libre software and corporate involvement. The |
16 |
>> profit motive has the potential to devastate community-oriented |
17 |
>> operations, be they libre software, swimming pools, common areas, |
18 |
>> municipal Internet, or even housing efforts. That potential for damage |
19 |
>> should be baked into any community-based operation's decision-making |
20 |
>> process. |
21 |
> |
22 |
> Greg KH has (IIRC) made the argument that it's the involvement of |
23 |
> corporations that has helped Linux grow exponentially, unlike the |
24 |
> BSDs. (IIRC, he attributed their involvement to the GPL, but that's a |
25 |
> different topic.) |
26 |
> |
27 |
|
28 |
The licensing absolutely had the attention of companies. A kernel, free |
29 |
of cost? And oh snap, the OS that started the free software movement -- |
30 |
these two projects aren't likely to change a whole lot in their |
31 |
licensing or approach. They're _the_ foundation of a system, so |
32 |
naturally if a business intends to build something, they'll want to |
33 |
build on the lowest, most stable level. |
34 |
|
35 |
Thankfully the kernel seems to have sane management; as long as Linus is |
36 |
around, anyway. Just recently AMD had some of their code rejected, so |
37 |
with a vigilant-enough team, you can effectively protect your project |
38 |
from monied interests (be it poor code or an attempt to manipulate). Now |
39 |
picture what might have happened if AMD was employing Linus or had some |
40 |
other sort of contract. (For the record, I use an AMD CPU and like it; |
41 |
they just happened to be the most recent corporation who's rejected code |
42 |
popped on my radar. No bias intended.) |
43 |
|
44 |
Growth comes from multiple things: quality, interest, cost, and |
45 |
extensibility. The kernel definitely has the last one; modules are a |
46 |
staple now. Maybe they weren't when it was first released. Quality has |
47 |
naturally improved over time, but I think that's the most variable part, |
48 |
since quality means different things to different people. Linux being |
49 |
extensible coupled with a permissive license allowed companies to fix |
50 |
bugs themselves and, if the code is good enough, spread their fixes to |
51 |
everyone else. Other companies may see that, and either take part in |
52 |
contributing code (for notoriety), or use it in-house to reduce costs |
53 |
and improve whatever metrics like uptime or what-have-you. A community |
54 |
then builds. |
55 |
|
56 |
None of those actors have to be corporate, money-seeking entities in |
57 |
order for growth to occur. Corporate involvement may have *accelerated* |
58 |
Linux's growth, but it had quality of design and code going for it, so |
59 |
growth was inevitable as it filled a huge niche at the time and |
60 |
continued to do so until the BSDs opened up and GNU Hurd was released. |
61 |
By that point, most heavy development was already on Linux, and the risk |
62 |
of switching to another OS/kernel -- after contributing code to Linux -- |
63 |
would be a hard sell to a company. BSD of course garnered a decent |
64 |
portion of the networking world and found its own niche, but Linux had a |
65 |
lot going for it early on that helped spike its growth, separate from |
66 |
*who* that growth came from. |
67 |
-- |
68 |
Daniel Campbell - Gentoo Developer |
69 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
70 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |