« Losing Bureacuracy and Developing an Open Source Career | Main | Whistle Blower Enhancement Act Introduced »

February 14, 2007

Comments

shmuel

The claim that "[m]uch like the pursuit of truth requires the open exchange and clashing of ideas in order that truth emerges, code requires collaborative scrutiny in order that stable code is produced" clashes with reality and the essence of collaboration.

Had this statement been true, open source code quality would have been noticeably better than proprietary software. The reality seems to be that many open source products are of low quality and quite a few proprietary products are quite good.

The need for collaboration in software development is undoubtedly a must, but this does not imply that the forum for this collaboration is unbounded and encompasses the whole of humanity. A rather limited group collaborating well tends to do a decent job of producing quality software.

Open source of large software packages requires specialization far beyond most people’s knowledge. Collaboration in such cases is, by and large, limited to small cabals. (This resembles the role of the rich in developed democracies.) Proprietary large packages, however, enjoy the benefit of well organized domain experts whose collaboration might be highly effective.

Open source is a well founded and a justified practice, but it has limits and constraints. As opposed to free speech, not every citizen has a stake in software and there is no proof that software democracy is the least of all evils.

Seeta Peña Gangadharan

While I am not a computer scientist, the quality of open source software versus proprietary software seems more defensible. In other words--I'm not sure I accept your first claim.

Leaving aside the ideology of the collaborative work ethic for a moment, I can see how a decentralized work process facilitates a more constant effort of "quality control." If a team of programmers is working at different times, in different places on a piece of software, that product is not held back by, say, marketing/release schedules or other strategic PR maneuvering factors that are characteristic of industrial firms today. By contrast, a team working on proprietary software is going to be bound by institutional norms and practices that limit the when-and-where of work process. "Quality control" is less about the end-product than about the overall institutional image or brand.

As for engaging the ideology of the collaborative work ethic and your claim above that "there's no proof that software democracy is the least of all evils," I think you raise some important issues.

The open source/free software movement does not strike me as the best way to popularize or, more simply, convey the idea that code has expressive qualities that may require free speech protections. It seems that the collaborative work process is an aspect of code's expressive qualities, but certainly not its defining feature. The openness of code--the ability to see it, copy it, play with it, mash-it-up--and not necessarily the group-process seems more important.

In other words, the ordinary person needs to understand code--how it is automatable, manipulable, flexible, etc.--in order to be aware of code's power to architect certain behaviors. The ordinary person needs to understand code in order to know how/when to prevent code from curtailing freedoms.

However, the ordinary person does not necessarily need to be confined to a participatory culture in order to become a digitally-able, digitally-expressive individual.

In short, the open source/free software movement is an impressive one, especially in the world of work. Yet, its success does not mean society should emulate its form of social organization in order to teach the value of understanding code.

Seeta Peña Gangadharan

While I am not a computer scientist, the quality of open source software versus proprietary software seems more defensible. In other words--I'm not sure I accept your first claim.

Leaving aside the ideology of the collaborative work ethic for a moment, I can see how a decentralized work process facilitates a more constant effort of "quality control." If a team of programmers is working at different times, in different places on a piece of software, that product is not held back by, say, marketing/release schedules or other strategic PR maneuvering factors that are characteristic of industrial firms today. By contrast, a team working on proprietary software is going to be bound by institutional norms and practices that limit the when-and-where of work process. "Quality control" is less about the end-product than about the overall institutional image or brand.

As for engaging the ideology of the collaborative work ethic and your claim above that "there's no proof that software democracy is the least of all evils," I think you raise some important issues.

The open source/free software movement does not strike me as the best way to popularize or, more simply, convey the idea that code has expressive qualities that may require free speech protections. It seems that the collaborative work process is an aspect of code's expressive qualities, but certainly not its defining feature. The openness of code--the ability to see it, copy it, play with it, mash-it-up--and not necessarily the group-process seems more important.

In other words, the ordinary person needs to understand code--how it is automatable, manipulable, flexible, etc.--in order to be aware of code's power to architect certain behaviors. The ordinary person needs to understand code in order to know how/when to prevent code from curtailing freedoms.

However, the ordinary person does not necessarily need to be confined to a participatory culture in order to become a digitally-able, digitally-expressive individual.

In short, the open source/free software movement is an impressive one, especially in the world of work. Yet, its success does not mean society should emulate its form of social organization in order to achieve the value of understanding code.

The comments to this entry are closed.