| |||||||||||||
|
| |||||||||||||
The result isn't quite what he thinks it isThe result isn't quite what he thinks it isPosted Dec 22, 2009 2:28 UTC (Tue) by BrucePerens (subscriber, #2510)Parent article: Meeks: Some thoughts on copyright assignment The big counter-example is MySQL. MySQL built a billion-dollar company to which Open Source was essential, but community development was avoided. They hired the good people. Of the two companies we can prove made a profit with Open Source, one didn't use community development. Could this mean that community development isn't even a good idea if you're out to make money? Of course, most Open Source projects are not out to make money, and for them community development is essential. We don't particularly need companies to do Open Source. But maybe it turns out that they don't need us either. Obviously, if it's got Open Source licensing, it's Open Source. Community development is an option that is always available to the community, who are never without the ability to fork the product if that is what is necessary to get it. Some folks theorize "fauxpen source", saying that Open Source without community is really fake. 1) it's a stupid name and 2) it's expanding the definition of Open Source by several more parameters than today: #11 there must be independent copyright holders and #12 there must be a low barrier to entry for developers. Those are always nice but not strictly necessary. Bruce
(Log in to post comments)
The result isn't quite what he thinks it is Posted Dec 22, 2009 4:55 UTC (Tue) by iabervon (subscriber, #722) [Link]
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.
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
The result isn't quite what he thinks it is Posted Dec 22, 2009 9:20 UTC (Tue) by AlexHudson (guest, #41828) [Link]
Michael's article isn't about making money, and your counter-example isn't - if it doesn't have a thriving developer community, which you admit, then it's not a counter-example in the context of his article.
Having a wildly successful project/product is not the same as having a thriving developer community, but I know which I would value more highly.
The result isn't quite what he thinks it is Posted Dec 22, 2009 11:04 UTC (Tue) by michaeljt (subscriber, #39183) [Link]
>Of the two companies we can prove made a profit with Open Source, one didn't use community
> development. Could this mean that community development isn't even a good idea if you're out > to make money? Too strong a development community might actually be a threat to some open source business models.
Threats and efficiencies Posted Dec 22, 2009 11:09 UTC (Tue) by sladen (subscriber, #27402) [Link] "Threat" has negative connotations; what's actually happening is the optimisation and evolution of a development process—in the long run it is better for the general good.
|
|
||||||||||||