The model of open-source development I've had in my head for a long time is closer to the activity of academic scientists than it is to the mass market activity of Silicon-Valley-Holly-Wood.
[ Home | Articles | Account | People | Projects | FAQ ] 
The model of open-source development I've had in my head for a long time is closer to the activity of academic scientists than it is to the mass market activity of Silicon-Valley-Holly-Wood.
Scientists toil long and hard in semi-isolation, fighting constant battles for funding and acclaim. They collaborate by leveraging the results of others, not by selflessly improving them. They are driven by a motivation that is necessarily independent of religious or monetary ideology.
Free Software started out this way, as a scientifically motivated activity. But scientific collaboration faded as the majority aped the richest man in the world, so another man promulgated his religious (i.e. unproven) reasons for carrying on. Later others found they could sell specific dominance games based on open source to investors willing to try anything to unseat that rich man. And here we often discuss how the reality of open-source development is different than the marketing claims. A better question might be just why did the marketing claims for open source get separated from reality.
I think with a little re-examination of the hype and people's underlying motivations we would see an increase in self-interested collaboration of the kind that has produced for century after century in the scientific world. You can't expect the many to learn enough of the intricacies of your project to make a significant contribution. But if your project has merit you should be able to expect the few to come out of the woodwork and help it along for their own reasons. If they are not confused by the glare and static flying around that has nothing to do with the source.
I just thought I'd like to say that that's possibly the most lucid description of the open source phenomenon I've seen in a very long time. That's all. :-)
When I interviewed for my first really serious programming job (product development manager at Working Software, I commented to company president Dave Johnson that I'd read that the software industry is a lot like the entertainment industry.
His reply was a somewhat sorrowful "If you only knew".
I think the context in which I originally read it was that the software industry is very faddish and full of hype, but it is also full of scams, and at least at times has had widespread use of cocaine and speed among the higher paid people.
I have this to say about the software industry in my page The Cross-Platform Manifesto:
In the world I came from pursuits like software development were supposed to be clean and pure things, exercises to stimulate and enrich the mind and advance the cause of reason and promote the betterment of human existence.
Instead the industry which appears to be the main driving force behind the tremendous recent growth of the world economy, especially the US economy, is in my opinion a cancer that is desperately in need of the surgeon's knife.
The "world I came from" was academia - science, in particular, I originally studied to be an astronomer (I assisted with some research on the 200" and 60" telescopes at Palomar Mountain) and later switched to Physics (I also did some high-energy physics work at CERN, in Geneva, Switzerland).
A nice article supporting your claim is here
That's also how I see it too. I definitely agree that there are a lot of people in this area who are on the pursuit of gaining knowledge and sharing it, rather than gaining and keeping it for purposes of increasing the bottomline.
One reason why it became that way was due to the nature of Unix itself. And that can be shown by looking at how programs were written in the early Unix times. I've been reading the Lion's Commentary of Unix 6th Edition and there are several glaring ideas that seemed to jump right out from the source code was three things and they are as follows: Continuity, Uniformity and Simplicity.
One proof of Continuity was the C language itself. In the book, there is a section in there describing the addressing modes of the machine and they are:
Uniformity in Unix during that time was expressed both in the language and the operating system. At the language level, uniformity was used in associating the length of a register and memory location to the type of an lvalue. It basically assumed that an lvalue will just be an int or char. And for untype lvalues, int was used as its default length. At the OS level, they used the file as the medium of getting data from devices, etc. I think there's no need to expound on that. However, uniformity would soon be taken away too with the introduction of ports. I think I know how they must have felt when ports were added in Unix. IMHO, breaking from the file and piping metaphor was a bad decision :-)
The last of it was simplicity. Looking at the source codes, one could easily see how simple the structures were and how small the functions were written. Moreover, the entire source was only about 9 KLOC.To quote:
Not least amongst the charms and virtues of the Unix Time-sharing System is the compactness of its source. The source code for permanently resident "nucleus" of the system when only a small number of the peripheral devices is represented, is comfortably less than 9000 lines of code.It has been suggested that 10,000 lines of code represents the practical limit in size for a program which is to be understood and maintained by a single individual.
From the above quote, simplicity was the reason that allowed an individual to approach Unix and learn from it with ease.
In summary, these three ideas are my best reasons why I stayed with the principles of Unix simply because it allowed me to learn it with ease and apply the concepts that were learned from it with ease as well. Moreover, that could be the reason why I am posting messages here.
Anyway, I think I've written enough. Enough with my ramblings worth 2 cents. Thanks.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!
del.icio.us
Digg
Google bookmark
reddit
Simpy
StumbleUpon
Furl
Newsvine
Technorati
Tailrank