Comments on: Musing about “commercial” development of Linux

By: Shivanand

Shivanand — Mon, 05 May 2008 07:22:16 +0000

I used to work for Novell, and depending upon which project you work for, the level of contribution and more importantly it’s motive changes quite a bit.

There are teams that work solely on the kernel, and are tasked with improving quality and adding extensions to make life easier for other teams.

There are also several teams, that write peripheral code that strictly stay within the confines of Novell’s specific distribution, but it later adopted by several others.

Some examples 3D desktop (I think it was called Beryl or some such thing), FSpot (iphoto like app), the Gnome music manager (I forget the name). All of these were then adopted by others like Ubuntu.

Apart from these there are also developers who commit code, coz it makes their task easier (as you hypothesized). Typical examples would be developers of storage solutions using linux or data center management apps, that need some infrastructure components in the distro, to get their task done.

But, I think that most part of that 70% is due to companies developing solutions on top of linux, and that requires certain features in the core and hence the motive is mostly to enable selling linux based solutions.

By: Jitendra

Jitendra — Mon, 28 Apr 2008 19:52:45 +0000

Hey JP, Jitendra from SezWho here…Too bad about the Phishing attack…Please let me know if I can do anything to help out with restoring the site. Thanks, Jitendra

By: Don Marti

Don Marti — Tue, 22 Apr 2008 23:45:44 +0000

Linux kernel developers who work for companies have to be collaborationally amphibious: answerable both to management and to the rest of the kernel developers, some of whom work for the employer’s competition. A developer can’t get too wild and woolly, working on something for the kernel that’s completely unrelated to the employer’s interests, or singlemindedly push for the employer’s interests in a way that would hurt other collaborators.

By: Vijay Singh Riyait

Vijay Singh Riyait — Tue, 22 Apr 2008 22:29:50 +0000

The consclusions of the report don’t surprise me but as yourself I have no way of proving or disproving it. What I do know is that companies such as Novell, RedHat, Sun and IBM have kernel developers directly contributing to the Linux Kernel. The OSDL has been supported by a range of Global Organisations and under which Linus Torvalds and others work. I believe this was a necessary step to make the step in to the Enterprise. At the end of the day hardware has to be bought for testing/porting, regression tests have to be performed, third party device drivers have to be incorporated which all needs resources and money. As Linux has become a core strategy for many companies such as IBM and Oracle then they have contributed towards its development in their own interests. I like Linus’s pragmatic approach towards the adoption of Linux and his realisation of having to work at the interface of propietary software and GPL’ed software. Kernel development is highly specialised and requires a certain skillset that not all developers have, so I’m not convinced there will ever be a huge pool of developers here or even whether it will be good for the Linux Kernel. You only have to look at some of the deep seated Debian issues to realise that there are major pitfalls. Linus and the Kernel developers have done an amazing job of managing such a complex process. I don’t know if people remember Linus’s handling of the change of Source Control to his own GIT tool – sheer genius!

By: David Dunwoody

David Dunwoody — Tue, 22 Apr 2008 22:27:45 +0000

A few developers are paid full-time primarily to work on open-source projects, but this is usually because open-source software development is a core business for their employer.

The long tail of contributors, comprising the vast majority of individuals, and perhaps the slender majority of the code, consists of people like me who only contribute because they need to fix or improve a tool they’re using in their day job.

Even then, I suspect the primary motivation for submitting a patch is often laziness; it’s easier to get a patch merged into the next version than it is to maintain an in-house patch.