| |||||||||||||
|
| |||||||||||||
The result isn't quite what he thinks it isThe result isn't quite what he thinks it isPosted Dec 22, 2009 4:55 UTC (Tue) by iabervon (subscriber, #722)In reply to: The result isn't quite what he thinks it is by BrucePerens Parent article: Meeks: Some thoughts on copyright assignment
I'm sure there are plenty of examples of companies that made successful software products without community involvement (including, for example, Microsoft). It would be reasonable to guess that this is not incompatible with that software being open source. Releasing the source under an open source license is not so big an impediment to sales in many areas that free labor is needed to make the total viable.
On the other hand, I think community involvement is important to making open source actually matter. Sure, licensing can make sure that you are able to make changes, and that you are permitted to make changes, but what's the big deal if you (and people like you but more interested in this particular software) never actually do make changes? Without community involvement, there is still the fact that the software doesn't cost any money, that it can be procured without a business transaction, that there's less potential liability for users, and that there's essentially automatic source escrow in case the owner falls apart. But I think the ideological basis for open source software is that, as technically competent and interested users use it, they generate improvements for their own benefit and share them, advancing the state of the art; and this pretty much implied community involvement.
(Log in to post comments)
The result isn't quite what he thinks it is Posted Dec 22, 2009 7:44 UTC (Tue) by jmm82 (subscriber, #59425) [Link]
I find most programmers love to write new code, but hate matanaince and
Most good open source projects pick up external funding to productize the
We may not need companies but everyone needs money to live. Let's face
The result isn't quite what he thinks it is Posted Dec 22, 2009 16:38 UTC (Tue) by iabervon (subscriber, #722) [Link]
Most programmers hate to write documentation, but if not all users are programmers, it stands to reason that there are users who like writing documentation. In fact, my experience is that interested users who aren't programmers tend to generate a lot of explanations for confused new users, and these users are eager to write documentation to avoid having the same questions to answer all the time. Of course, getting good documentation out of this process requires having a process in place for getting documentation from contributors into the project state, getting it organized in some usable way, and then into the hands of new users. It also depends on the documentation source being in a form that people who like to write about programs like to write. Furthermore, someone with an interest in process management and document organization has to work out a procedure for keeping the documentation organized as the project grows and more documents arrive. Random factoid: in the git project history, of the 19785 commits leading up to v1.6.5, 4086 of them (20.6%) touch the "Documentation" subdirectory, and 3096 of them (15.6%) touch the "t" (tests) subdirectory. As far as I know, there's nobody who has writing documentation for inclusion in the git project as a specific job duty.
Programmers don't like to do maintenance, but they also don't like to work on badly maintained code. Stuff gets cleaned up when it's more trouble to work on interesting stuff despite it than to clean it up. This is probably better than most of the commercially driven world, where clean up is only generally supported when the messiness is actually problematic, not just annoying.
The result isn't quite what he thinks it is Posted Dec 23, 2009 0:05 UTC (Wed) by jmm82 (subscriber, #59425) [Link]
Last time I checked about 75% of code contributions to Linux kernel were by people being paid. So regardless of if they are paid to "write documents" they are paid to see that the project does well.
Also, the Documentation dir in the Linux kernel is much better then it used to be, but it is not sufficient to understand the kernel.
From my personal experience learning the kernel I have found a lot of the tutorials Greg KH has written helpful(along with a few other people like Rusty Russell), yet documentation is still the exception rather than the rule and that is sort of realistic for the pace that the kernel moves. Also, most documentation is out of date, but that is fine it is usually enough to dive into the code.
The Linux kernel is obviously an example of how every project should turn out, but it is mostly funded programmers. The kernel is so complex and the politics are so great that it is relatively impossible for an unpaid community member to contribute significant code to the kernel. I am not saying it doesn't happen, but it seems to be getting harder and harder to "catch up" enough to write good kernel code without doing it full-time. That does not mean unpaid community members do not contribute in others ways, but the paid programmers are the foundation that keeps the kernel in shape.
While I believe external funds are necessary to create a good open source project. I also believe that companies can fund projects without hijacking all contributions. Your example the Linux kernel being proof.
I really enjoyed the article by the way. I forgot to mention that in my last post.
The result isn't quite what he thinks it is Posted Dec 23, 2009 3:18 UTC (Wed) by iabervon (subscriber, #722) [Link]
That's all true of the linux kernel project, but I was talking about git. The kernel has quite a few more commits than that, and a much smaller portion touch the Documentation directory (which makes sense, because the documentation that people mostly need is in the separate "man-pages" project, not the kernel's Documentation directory. (Also, the kernel never had a version 1.6.5.)
As far as I know, the people paid to work on git are: Junio, whose employer lets him work a day a week on it; Shawn, who works on git-related projects in his "random useful stuff" time as a Google employee; and presumably the scattering of people who work for git hosting companies and also make some changes to the project. There are probably a number of others who have convinced their employers to use git and therefore can fix bugs and contribute patches if their site runs into the problem.
I think that, to the extent that there's corporate sponsorship of git development, it's either essentially an employee benefit or is corporations acting as technically competent end users and scratching their itches, which is somewhat of a different situation from the relationship between Linux and corporations.
The result isn't quite what he thinks it is Posted Dec 23, 2009 4:26 UTC (Wed) by jmm82 (subscriber, #59425) [Link]
My apologies I heard git and I immediately thought Linux kernel.
Git is a great example of the type of project which thrives in open
My current favorite Open Source project is the Chromium browser. It is a
|
|
||||||||||||