Quote:
Originally Posted by
osanthropologis
Firstly, I would like to apologise to everyone who responded so quickly and with such interest. The broadband in my house has been down for a week and BT have been too lazy to fix it till now.
It happens. Glad to see you back.
Quote:
Some very interesting comments. I think it's great that you bring up selfish gene Corona because that sort of a Darwinian model is right at the heart of the course I'm doing.
Careful how you toss around those terms -- someone could lose an eye!
I used the word "selfish". I didn't mention Darwin or the "selfish gene". As far as I knew, there wasn't a whole lot of biological reproduction involved in open-source software, but now I wonder what I'm missing.
Quote:
I don't know if you've heard of Zahavi and Signaling Theory? Basically, the way I'm looking at it is that there exists a culture of exchange in Linux because the creators and troubleshooters invest their time and energy into this one big project. If we want to look at it in Darwinian terms, there should be a benefit or a perceived benefit which equals or exceeds that cost. The intensity with which one contributes to the community project infers a sort of cultural status and an expectation of reciprocity. So in that way it may be looked at as a gift economy, I think.
The vast majority of a program's users probably aren't programmers, their ability to reciprocate is limited. But we don't care -- their use costs us absolutely
nothing. Though they're occasionally surprised
we aren't devoted to
them, unlike what they'd expect of a commercial entity!
Maybe if I used a more concrete example... I use the Gentoo linux distribution. All I'm
required to do is obey the license agreement. I can download a CD, install, and do what I want without one word expected from me, and if it has everything I need working perfectly, no word needed from me either.
If I have legitimate problems with it, I'm
invited to file a proper bug report on bugs.gentoo.org, answer the dev's questions with further information, et cetera. I'm under no
obligation to do so but it just makes sense -- it's in my best interests to let them help me.
Since I'm a programmer, sometimes I can solve bugs myself. I'm
invited to file bug reports explaining my solutions, though I'm still not
obligated, but it just makes sense -- by giving it to them, it spares me a lot of future effort, since they'll give it back to me in a convenient pre-packaged form. I won't have to fix it myself anymore, it'll just come that way.
Now throw together several users working on the same bug. Some can only contribute information, some can contribute expertise, and some have access to the Gentoo tree to get the fix applied for good, and it's all in their naked self-interest to get the problem fixed, so they work together. This is the open-source ideal, I think. It doesn't work equally well for all software problems but can work quite well when it does.
One recurring problem is features, i.e. someone wants a feature added, not a bug fixed. Unless you convince some programmer or other that it's a really great idea to add this feature, they'll be
ignored or given alternatives. If someone has the expertise to write the modifications themselves they stand a better chance of getting it incorporated, but it's still not a sure thing, especially if it means a lot of work. There were serial-terminal enhancements available for PUTTY for years, but it took them years to incorporate it properly, the writer of the add-on kept his own independent PUTTY version available in the meantime.
Another problem is very disused features or programs. Unless a bug in them causes gaping security holes, developers might not care enough to fix it, and might resort to just removing it.
It's not just a mob of users, though. Someone had to create the project in the first place -- though as is often the case, he built it because
he wanted it. Some people must also volunteer significant efforts to maintain this code and community infrastructure. Their motivations are a little harder to pin down, and frequently vary. Keeping the same core developers onboard in the long term is a perennial problem.