Our paper this week is Echoes of Power: Language Effects and Power Differences in Social Interaction which explores how to identify power differences between people in a domain independent way. http://www.mpi-sws.org/~cristian/Echoes_of_power_files/echoes_of_power.pdf.
The central thought is that the way in which one person "coordinates" their linguistic style to the style of the person or group with which they are communicating can be an indicator of the power relationship between them. If this is true for open source software as well as for the Wikipedia and Supreme Court corpa they explore, it can be exploited to create a power hierarchy in these open source projects. With a graph of the power network it may be possible to infer project outcomes based on various network metrics of that power network.
This paper also makes me wonder to what extent it could be extended to code style. The references suggest that they are building on some other work that finds a prose style that is characteristic for an individual. Given the high level of semantics in the tokens and rigid syntax in a computer program is it even possible to find some domain independent marker of programmer style? I know this has been extensively explored and this paper makes me more curious to see what has already been found.
Friday, January 25, 2013
Friday, August 10, 2012
Free Software and Communism
Sac State has a program through MSDN that provides their current OS for free to the students. UC Davis does not (or at least I haven't found it yet if they do). Curious. But the bigger issue is my changing thoughts about what I expect to spend for software.
In the 30 years I have had an association with Microsoft I have probably spent in excess of $10,000 buying their products. Despite this continued relationship Microsoft doesn't know I exist and provides some of the worst customer service I have ever experienced. I have had a few times where it was a bug in their product I wanted to talk about and have been given the run-around or been asked to fork over $100 to talk to someone. Microsoft has historically charged too much for an inferior product for far too long. They seem to relate to the consumer market the way a farmer relates to a field crop.
While I myself am not the sort inclined to tinker with an OS, many people I have known are. The Linux and open source movement have been incredibly empowering for those of us who have the capability and inclination to tinker. First it is free. That of course is a huge advantage seeing that Microsoft has the audacity to float an undiscounted price for Windows 7 that is over $500. If I hadn't been getting their products for free from school I would have abandoned them long ago. There is a certain hubris that the people they might want to recruit to write operating systems would be asked to spend a significant amount of money in their education using scarce resources to buy their products. It would be in their interest to ensure that every CS major receives a generous support from them if for no other reason than good PR. So at some level good CS students must find it galling that they are asked to pay a high price for an inferior product. Is it any wonder that it is often students are the most creative in finding ways to avoid paying for their products?
Since it is CS students and the professionals they become use software as their tools of the trade daily over their careers, it makes perfect sense that they will be the most critical consumers of these tools. Any worker who uses a tool daily will choose and maintain her tools with great care. When the market provides only a mediocre tool, there is an opportunity for some worker to turn their attention to the tool. Of course many workers do not have the skills to tinker with their tools. A machine shop worker probably does not have the technology at hand to tinker with a high-precision lathe. But a software engineer with the source code for a major piece of system's software does. While it is only a minority of these engineers who are inclined to tinker, it is enough to create an alternative in the tool market. We have certainly seen that exhibited in the market for open source software and the active support it gets.
In some idealized libertarian universe, these talented tinkerers could have formed an alternative to Microsoft and made some money from their collective efforts. But creating and managing a business is not a trivial affair and certainly not what motivates talented software engineers. Engineers in general are great admirers of functionality and not of management. Their are significant intrinsic rewards to the creation of a good product but few in the marketing and sales of that product to them. Yes, there are some rare individuals who excel at both. But their scarcity relative to the number of highly talented engineers is precisely my point. The open source model was appealing to them because it gave them control over their means of production and empowered them to do things for their clients that are impossible in a closed model.
Some have tried to cast these engineers as proto-communists contributing to a common good. (from each according to his ability, to each according to their need). But if that attitude exists in the open source community, I have not yet seen it baldly stated. Rather than being driven by some ideological position, the market seems to be moving along a highly pragmatic path of least resistance. The closed software market has not met their needs to provide high-quality, responsive solution to the clients using their tools. Instead of forming highly responsive relationships with these integrators, the companies seem to have put their needs behind the company's. Doesn't it make sense that someone responsible for providing the company with a high-quality web server would be more inclined to support Apache than IIS? It is in their self-interest to choose this simply because they have greater control over the resolution of any problem or enhancement than they would over a close product at the leading edge of its deployment. The fact that other people gain access to a high quality product as a consequence is irrelevant to them and takes nothing from them. In fact, the widespread adoption of Apache enhances their marketability since employers who desire to avoid IIS, for whatever reason, will seek them for employment.
No, I am not finding any incipient communism in the growing open source movement but instead a marketplace that is responding to the maxim 'information wants to be free" plus an enlightened self-interest among the most talented software engineers of our day. They seem to be having a blast. Now if we can only figure out where the margins of this new market lie.
In the 30 years I have had an association with Microsoft I have probably spent in excess of $10,000 buying their products. Despite this continued relationship Microsoft doesn't know I exist and provides some of the worst customer service I have ever experienced. I have had a few times where it was a bug in their product I wanted to talk about and have been given the run-around or been asked to fork over $100 to talk to someone. Microsoft has historically charged too much for an inferior product for far too long. They seem to relate to the consumer market the way a farmer relates to a field crop.
While I myself am not the sort inclined to tinker with an OS, many people I have known are. The Linux and open source movement have been incredibly empowering for those of us who have the capability and inclination to tinker. First it is free. That of course is a huge advantage seeing that Microsoft has the audacity to float an undiscounted price for Windows 7 that is over $500. If I hadn't been getting their products for free from school I would have abandoned them long ago. There is a certain hubris that the people they might want to recruit to write operating systems would be asked to spend a significant amount of money in their education using scarce resources to buy their products. It would be in their interest to ensure that every CS major receives a generous support from them if for no other reason than good PR. So at some level good CS students must find it galling that they are asked to pay a high price for an inferior product. Is it any wonder that it is often students are the most creative in finding ways to avoid paying for their products?
Since it is CS students and the professionals they become use software as their tools of the trade daily over their careers, it makes perfect sense that they will be the most critical consumers of these tools. Any worker who uses a tool daily will choose and maintain her tools with great care. When the market provides only a mediocre tool, there is an opportunity for some worker to turn their attention to the tool. Of course many workers do not have the skills to tinker with their tools. A machine shop worker probably does not have the technology at hand to tinker with a high-precision lathe. But a software engineer with the source code for a major piece of system's software does. While it is only a minority of these engineers who are inclined to tinker, it is enough to create an alternative in the tool market. We have certainly seen that exhibited in the market for open source software and the active support it gets.
In some idealized libertarian universe, these talented tinkerers could have formed an alternative to Microsoft and made some money from their collective efforts. But creating and managing a business is not a trivial affair and certainly not what motivates talented software engineers. Engineers in general are great admirers of functionality and not of management. Their are significant intrinsic rewards to the creation of a good product but few in the marketing and sales of that product to them. Yes, there are some rare individuals who excel at both. But their scarcity relative to the number of highly talented engineers is precisely my point. The open source model was appealing to them because it gave them control over their means of production and empowered them to do things for their clients that are impossible in a closed model.
Some have tried to cast these engineers as proto-communists contributing to a common good. (from each according to his ability, to each according to their need). But if that attitude exists in the open source community, I have not yet seen it baldly stated. Rather than being driven by some ideological position, the market seems to be moving along a highly pragmatic path of least resistance. The closed software market has not met their needs to provide high-quality, responsive solution to the clients using their tools. Instead of forming highly responsive relationships with these integrators, the companies seem to have put their needs behind the company's. Doesn't it make sense that someone responsible for providing the company with a high-quality web server would be more inclined to support Apache than IIS? It is in their self-interest to choose this simply because they have greater control over the resolution of any problem or enhancement than they would over a close product at the leading edge of its deployment. The fact that other people gain access to a high quality product as a consequence is irrelevant to them and takes nothing from them. In fact, the widespread adoption of Apache enhances their marketability since employers who desire to avoid IIS, for whatever reason, will seek them for employment.
No, I am not finding any incipient communism in the growing open source movement but instead a marketplace that is responding to the maxim 'information wants to be free" plus an enlightened self-interest among the most talented software engineers of our day. They seem to be having a blast. Now if we can only figure out where the margins of this new market lie.
Wednesday, August 1, 2012
A First Look at Commit Data for an Open Source Software Project
I got a little something to sink my teeth into. I am looking at commit data for some open source projects. This is mostly an exercise in regaining my sql chops and learning R. Here is my first plot:
The plot has the alias of the submitter along the X and the timestamp along the Y. What you can see for this one project is that there are two heavily dedicated submitters who both started working on the project about the same time, one who is more sporadic and started shortly before the two of them and two who appear to have started the project but only periodically commit although their activity is relatively consistent over the entire length of the project. What is somewhat surprising is how many there are who have almost no commit activity (there is some doubt regarding whether this alias is the submitter or committer although it is supposed to be the commit id). It seems odd that someone would have gained committer status and then stopped commiting. Will I see this pattern in other projects? Who are these heavy committers and how do they differ in role from the people who appear to have started the project?
The plot has the alias of the submitter along the X and the timestamp along the Y. What you can see for this one project is that there are two heavily dedicated submitters who both started working on the project about the same time, one who is more sporadic and started shortly before the two of them and two who appear to have started the project but only periodically commit although their activity is relatively consistent over the entire length of the project. What is somewhat surprising is how many there are who have almost no commit activity (there is some doubt regarding whether this alias is the submitter or committer although it is supposed to be the commit id). It seems odd that someone would have gained committer status and then stopped commiting. Will I see this pattern in other projects? Who are these heavy committers and how do they differ in role from the people who appear to have started the project?
Tuesday, July 10, 2012
Will Open Source Software Someday Rule the World?
I've been listening to the ChangeLog and reading a lot about the explosive growth of open source software. There is no doubt that this phenomenon is creating innovative products and exploring new ways for creative individuals to self-organize. I forgive young software engineers for thinking this is a complete game changer and that all software in the future will be developed using this model. Perhaps they're right but I don't think so. I want to explore this assertion and see what the data shows. Let's start with the Apache Foundation.
In their how-it-works page, they describe how the Apache server source code was taken from the NCSA HTTPD but was orphaned when the original developers moved on to other projects. Brian Behlendorf created a mailing list of other admins using the product to communicate patches on that code base. That original group continued to organize and formalize. They then began to sponsor allied projects. All the projects were organized to grant authority to volunteers after they had proven their abilities; a culture of meritocracy. This group was not only users of the products, they also had the skills to modify the product and the reasons to do so. Their working lives revolved around the functions of these products and many changes were either self-serving or would please they people who they served.
These open source projects create a resource that is designed as non-excludable and non-rivalrous. Anyone who find the repository is welcome to download the software product and use it. The use of the product by one person does not preclude the use by anyone else. In many ways this is the classic public goods model. What is interesting is how the FLOSS projects do not seem to suffer from the free loader problem or any form of tragedy of the commons.
Someone who downloads a software product from a FLOSS (Free/Libre Open Source Software) repo will often have access to a significant asset. The Apache web server is a sufficient example. This product competes quite well against products from for-profit enterprises and could possibly attain a dominant position in the marketplace, if it hasn't already. But to achieve and maintain a market position like this required a significant investment in effort at one point. In the case of the Apache webserver it was NCSA. If the creation of a superior product that is then gifted to the public, this matter would be easily understood. The Apache webserver was not a single creation that was gifted since the needs of webservers have changed dramatically over the years. In fact it was the new needs that motivated the creation of the project in the first place. Since the product was already a reasonable base upon which to build, and since the needs affected many users of the product, a natural mutual interest was created and nurtured by the communications channels that were available. This is still the model for most people of a FLOSS project.
If the common asset were open to modification by anyone who had access to it, it would surely have been doomed by the tragedy of the commons. Each person who thought they knew what they were doing would have made changes and some of them would have broken the system. The form of ownership that evolved was that only a subset of people would have commit rights and they already had established enough trust in each other to be assured that they would act for the common good of the project. Since these "managers" depended upon the product, their interests converged.
This software, unlike physical public goods, could be consumed without limit as it existed. But to remain viable in the marketplace, it needed to evolve to meet the changing requirements, lest it become obsolete. Here is where the Apache project had a distinct advantage; each consumer also had the requisite tools and knowledge to adapt the product for the changing needs. These changes were insignificant compared to the complete body of code and the cost of creating each patch was also insignificant to the cost of changing to another product. Once the patch had been created, the marginal cost to share it with the community was insignificant and its value to the individual was limited unless that developer/user chose to take on the responsibility for creating a marketable product from the FLOSS base. Since this was not compatible with that person's core mission (we assume), they chose to contribute. Since each person was acting in their self-interest, the collective effort not only allowed the product to evolve to meet new demands but could also spawn new products as needs diverged.
So what are the elements to create a successful FLOSS project? First, there must be some base of code that provides enough out-of-the-box functionality to answer some need by a user. Second, there must be some core set of users who have a shared vision of what the product is and can agree on commits to that product. It seems as if this core group must initially be the primary source of commits as well as be willing to support new users of the product. Third, the end-users of the product must also possess the tools, skills and motivation to patch the product when it does not meet their needs and offer these patches back to the project. It is possible that the work of Ronald Coase may be helpful in the analysis of FLOSS projects.
The FLOSS market has changed over the years and it appears that other models are appearing. In particular the market for ERP software in FLOSS looks very different. In this case, the initial investment to create such a product is much higher and the market much thinner. What organizations now seem to try is to offer a "community version" of their product which is appealing to some subset of the market and then use it as a loss leader or teaser to find others who might be willing to purchase a traditional license for the full-product.
Another model I see in the repos is people who have come up with a relatively small widget which they have gifted. It is not clear if their hope is to spawn a new open source project from this seed or whether they are just engaging in a form of gifting. My instinct tells me the chances of a relatively small product spawning a viable new project is small. First, it may make more sense for the the consumer to merely copy the code into their own repository rather than take the product in as a component. If that is the case, the opportunity to achieve a back channel of patches to the product will be undermined and the product will remain static. If there are any changes in the needs, the product is likely to wither from the lack of contributions to keep it viable in the market. Second, without a core of developers who see value in providing the oversight to the project that is needed to avoid code rot, the burden will fall entirely upon the original developer. If that developer does not make frequent mods to the code herself, it is likely to become a burden since there will be a limit to the time that the developer will devote to that one product.
Eclipse seems to be following a different model where instead of individuals supporting the product it is organizations. This is an area I need to research since it is not clear to me how IBM benefits from the expense in Eclipse.
In their how-it-works page, they describe how the Apache server source code was taken from the NCSA HTTPD but was orphaned when the original developers moved on to other projects. Brian Behlendorf created a mailing list of other admins using the product to communicate patches on that code base. That original group continued to organize and formalize. They then began to sponsor allied projects. All the projects were organized to grant authority to volunteers after they had proven their abilities; a culture of meritocracy. This group was not only users of the products, they also had the skills to modify the product and the reasons to do so. Their working lives revolved around the functions of these products and many changes were either self-serving or would please they people who they served.
These open source projects create a resource that is designed as non-excludable and non-rivalrous. Anyone who find the repository is welcome to download the software product and use it. The use of the product by one person does not preclude the use by anyone else. In many ways this is the classic public goods model. What is interesting is how the FLOSS projects do not seem to suffer from the free loader problem or any form of tragedy of the commons.
Someone who downloads a software product from a FLOSS (Free/Libre Open Source Software) repo will often have access to a significant asset. The Apache web server is a sufficient example. This product competes quite well against products from for-profit enterprises and could possibly attain a dominant position in the marketplace, if it hasn't already. But to achieve and maintain a market position like this required a significant investment in effort at one point. In the case of the Apache webserver it was NCSA. If the creation of a superior product that is then gifted to the public, this matter would be easily understood. The Apache webserver was not a single creation that was gifted since the needs of webservers have changed dramatically over the years. In fact it was the new needs that motivated the creation of the project in the first place. Since the product was already a reasonable base upon which to build, and since the needs affected many users of the product, a natural mutual interest was created and nurtured by the communications channels that were available. This is still the model for most people of a FLOSS project.
If the common asset were open to modification by anyone who had access to it, it would surely have been doomed by the tragedy of the commons. Each person who thought they knew what they were doing would have made changes and some of them would have broken the system. The form of ownership that evolved was that only a subset of people would have commit rights and they already had established enough trust in each other to be assured that they would act for the common good of the project. Since these "managers" depended upon the product, their interests converged.
This software, unlike physical public goods, could be consumed without limit as it existed. But to remain viable in the marketplace, it needed to evolve to meet the changing requirements, lest it become obsolete. Here is where the Apache project had a distinct advantage; each consumer also had the requisite tools and knowledge to adapt the product for the changing needs. These changes were insignificant compared to the complete body of code and the cost of creating each patch was also insignificant to the cost of changing to another product. Once the patch had been created, the marginal cost to share it with the community was insignificant and its value to the individual was limited unless that developer/user chose to take on the responsibility for creating a marketable product from the FLOSS base. Since this was not compatible with that person's core mission (we assume), they chose to contribute. Since each person was acting in their self-interest, the collective effort not only allowed the product to evolve to meet new demands but could also spawn new products as needs diverged.
So what are the elements to create a successful FLOSS project? First, there must be some base of code that provides enough out-of-the-box functionality to answer some need by a user. Second, there must be some core set of users who have a shared vision of what the product is and can agree on commits to that product. It seems as if this core group must initially be the primary source of commits as well as be willing to support new users of the product. Third, the end-users of the product must also possess the tools, skills and motivation to patch the product when it does not meet their needs and offer these patches back to the project. It is possible that the work of Ronald Coase may be helpful in the analysis of FLOSS projects.
The FLOSS market has changed over the years and it appears that other models are appearing. In particular the market for ERP software in FLOSS looks very different. In this case, the initial investment to create such a product is much higher and the market much thinner. What organizations now seem to try is to offer a "community version" of their product which is appealing to some subset of the market and then use it as a loss leader or teaser to find others who might be willing to purchase a traditional license for the full-product.
Another model I see in the repos is people who have come up with a relatively small widget which they have gifted. It is not clear if their hope is to spawn a new open source project from this seed or whether they are just engaging in a form of gifting. My instinct tells me the chances of a relatively small product spawning a viable new project is small. First, it may make more sense for the the consumer to merely copy the code into their own repository rather than take the product in as a component. If that is the case, the opportunity to achieve a back channel of patches to the product will be undermined and the product will remain static. If there are any changes in the needs, the product is likely to wither from the lack of contributions to keep it viable in the market. Second, without a core of developers who see value in providing the oversight to the project that is needed to avoid code rot, the burden will fall entirely upon the original developer. If that developer does not make frequent mods to the code herself, it is likely to become a burden since there will be a limit to the time that the developer will devote to that one product.
Eclipse seems to be following a different model where instead of individuals supporting the product it is organizations. This is an area I need to research since it is not clear to me how IBM benefits from the expense in Eclipse.
Thursday, June 28, 2012
Parnas on Open Source Software
oHere is a link to a chapter that was co-authored by David Parnas on open source software. http://mitpress.mit.edu/books/chapters/0262562278chap6.pdf In it, he expresses some concerns about the ability of open source software projects to produce high-quality products.
There is also this link which I like... http://economics.mit.edu/files/1125. It has to do with qualitative research in economics
There is also this link which I like... http://economics.mit.edu/files/1125. It has to do with qualitative research in economics
Wednesday, June 27, 2012
Does Marx offer any insight into FLOSS?
FLOSS (Free/libre open source software) has occasionally caused people to ask if it is communist over the past decade. I'll ignore the trolling aspect that this question raises and jump right to the ways in which it can offer some frisson with FLOSS.
You cannot look at FLOSS for long before seeing the communal aspect of these projects. Most recently the question was posed on Quora and I posted a lengthy answer there. (http://www.quora.com/Is-free-open-source-software-communist/answer/Dale-Fletter). I also answered a different question that I see as closely related having to do with how FLOSS has impacted commercial software development (http://www.quora.com/Software-Engineering/What-is-the-impact-of-the-open-sourcing-philosophy-on-proprietary-closed-software/answer/Dale-Fletter). Since that forum does not reward deep intellectualism and since this journal is my primary data base of ideas, I will try to repeat or improve my answer there.
A topic of discussion for the early economists was the tragedy of the commons. Since each person is naturally inclined to consume from the commons and make no contribution, this is a problem in a laissez-faire economy. (it is personally disturbing to me how little the current political parties that embrace libertarianism adequately deal with this fundamental problem). What I see in the current FLOSS market looks surprisingly like a reverse issue to the tragedy of the commons, let's call it the gift of the commons. In the FLOSS market consumption of the commons does not diminish it in any significant way. Yet because of the relationship people have with the commons, they are inclined to contribute to it leading to an increase in its value to everyone. This is clearly a way in which the assets are held in common for the good of everyone. It is also clear that many of these assets provide a means of production for many of the users of the commons. This forces the question, is this a form of communism?
To help me understand the question, I needed to put aside my own prejudices about communism and chose to educate myself on the source of much of its intellectual underpinnings in Karl Marx. The book I chose to read first is Karl Marx by Isaiah Berlin. I first tried to read The Capital/Das Kapital but abandoned it since his prose is painful and the progression of his ideas is glacial for a modern reader. The other advantage of Mr. Berlin's history is the cultural and intellectual context and the critical nature of his reporting. I highly recommend the book.
Marx had a deeply held point of view that has been largely debunked by the developments of the 20th century. Therefore his theory about class warfare and the inevitable fall of capitalism makes no sense any longer. However his early analysis of capitalism is surprisingly fresh and modern in its insight, if not always completely original. In my opinion, he was an empiricist, he believed that capitalism had inherent defects that were inimical to the inherent rewards of work and that without leavening, capitalism could not survive. I believe the history of the late 19th and all of the 20th century have proven this thesis to my satisfaction despite the current debate. What I find enthralling is how he seems to capture the spirit of many software engineers who contribute to FLOSS. There seem to be many motivations in their work and Marx, for me, seems to offer some insight into this emerging market. It is his intention to use a scientific method that includes economics and the other social sciences to observe, record, discuss, explain and theorize about what he saw as a model for the analysis of FLOSS.
Regarding qualitative analysis, Berlin observes, "This command to look for the most vivid expression of the universal in the particular, the concrete, the differentiated, the individual, to emulate the art and the realism of the biographer and the painter rather than the photographer and the statistician, is the peculiar legacy of German historicism." As I look at FLOSS, I intend to follow this command, at least for now.
While the broader concept of class means something very different today than it did at the time of Marx, let me first make some observations about class relative to FLOSS. Communication mediated by the software repositories created for FLOSS removed almost all traces of class that might intrude from outside. Many people involved do so anonymously and provide no meaningful picture of themselves outside of the project. This provides an opportunity for people to recreate themselves in this sphere. Coupled with the staunch support for meritocracy, someone with no power, status, or obvious class affiliation outside of the project could rise to the level of contributor. (it looks like anonymous contributors with commit rights don't exist in Apache but that needs more research). Beyond the hierarchy that exists due to this meritocracy, there does not seem to be any inherent class structure, at least within the confines of a project. Without a class structure, I don't see where any class friction can exist.
As I already observed, the commons is not diminished by the copying of the software. Also the project imposes no coercion for contribution. This is perhaps the most pure expression of the communist maxim of "from each according to their ability, to each according to their needs". (I note that the phrase, while popularized by Marx owes its origin to Louis Blanc). Of the abilities that contribute to the projects, there are many. Some have very fundamental needs to fix the errors in these machines to keep them running for the enterprises that are important to them. There are visionaries who pursue new features with an artistic zeal. Some fall in love (eroticize) the product and take a proprietary interest in making it the best possible product in the same way that Pygmalion created his beauty. The lack of a centralized plan would seem to diminish the utility of the final product but that is difficult to see in many cases.
Much has been written about the alienating effect of monads slaving over keyboards. Perhaps a motivation for contributors is the sense of belonging that active participation in a project community brings.
One of the aspects of FLOSS that most strikes me is that the utility of the projects does not cover the universe of software uniformly. There is a decided bent toward tools and utilities versus consumer products and other products that do not have well trained individuals as their primary consumers. By this I am talking about the preponderance of languages, web development and web deployment tools, databases and other tools of the trade. From the operating system to the creation of an industrial grade online service, it is possible to avoid paying a corporation any licensing fees. I am not aware of any period of human history when the tools of production have been so freely available. This represents another basic Marxist maxim that the workers should own the means of production. We now have an entire generation of web developers who are created significant value using the tools from the commons. It is their enlightened self-interest which causes them to contribute so as to further rationalize or extend these tools. Some even find ways to tweak the tools to create new market opportunities for themselves and garner personal rewards by bringing this value to market before anyone else.
It is the interplay between the commons and the for-profit marketplace that causes many people to question the label of communism. They call it a "gift-economy" or some other such label. What distinctions are they trying to paint? I still have much research to do in the area of alternative economies, in particular those related to the gift economy. However I am going to indulge my going in positions.
Wikipedia talks about how early file-sharing was a form of gift-exchange that fostered a sense of community. I'm not buying that. FLOSS has a very specific aspect that cannot be seen in music or most forms of art. When I buy a song, I now have a static object which will not change during the time it is of interest to me. Contrast that with a piece of complex software like an operating system. The utility of that download may last for a period of some years. However if it has become part of a larger system, I will not be inclined to abandon my investment of time in that larger system once that component is no longer completely compatible with the dynamic environment in which it exists. It is for this reason that large complex software has a value chain that includes periodic updates. And it is exactly this value chain that FLOSS most brilliantly fulfills. The collective work of the various parties who attach to that value chain ensure that the product is dynamic and continually adapting to its environment. As I become aware of new functionality that must be added to the version I have, I have some assurance that this project will have organically anticipated that need and already provided for it. Even if I am the first, there will be others who will benefit from what I may be forced to do as a matter of personal need. My contribution builds goodwill and community as I discuss my need with others who have the same or similar needs.
While I reject the idea of music file sharing as being similar to FLOSS as a form of gift economy, I completely agree that this community building is an inherent part of the FLOSS experience. Especially in their formative stages, FLOSS projects have a relatively small number of contributors. The inherent communication among these contributors creates a sense of personal intimacy that build community bonds. Trust grows. Shared context grows. Often new ideas sponaneously emerge from the discussion in one project that spawn another and a new project is born.
Another aspect of FLOSS that I find in Marx's writing has to do with the basic notion of work. In the traditional Theory X of work, an organization must provide incentives to work. Without them, people will be inclined to not produce. Both Marx and then later Theory Y suggest that work has intrinsic fulfillment. Taken with Maslow's hierarchy of needs, it appears that FLOSS attracts people who gain significant rewards from the support they give to FLOSS. What must be explored is to what extent this interacts with other forces to enable that. For example, if software developers who are most active in FLOSS are being paid by their employers to contribute, can we be assured that this has achieved some form of market stability? Software engineering salaries are still relatively high but they have begun to show some signs of market volatility as foreign countries have shown their ability to compete for this labor. There can be no doubt that some aspects of software engineering will become less financially rewarding in the future. Will this lead to a downturn in the FLOSS contribution?
Another interplay with FLOSS is those developers who were fortunate enough to have a financial success with an earlier product and now use FLOSS as an incubator for a new idea. Clearly anyone who has become independently wealthy does not represent a stable vision for the future of FLOSS.
FLOSS may become a proving ground for young talent. People in school or recently out who are still supported can afford to invest significant time contributing to a project of their choice. Is it possible FLOSS will become a form of Peace Corps where the young become apprenticed and learn their trade while simultaneously provide some societal good?
Modern economic thought does not see the world in the kind of binary fashion that was prevalent in the 1950s. Modern western economies are mixed with elements of both capitalism and socialism mixed. I cannot see any reason why there cannot be stable islands of communism that coexist in our economy. There are many utopian communities that have existed side-by-side for many years. Both models of economies seem flexible enough to allow for mutual coexistence.
The final point I see in FLOSS is the force of idealism and youthful optimism. Virtually all valley jobs involve a certain amount of kool-aid drinking. The most pure forms of capitalism involve a quasi-warfare mentality of competition in the marketplace. But just as effectively, you see many young people (and some older folks too) who become committed to an idealistic path that stands in stark opposition to the free-market capitalism. FLOSS seems to draw from this pool of talent as well. Perhaps it even offers some solace from the brutality of an unbridled capitalist environment and a place where people can go to mentally recuperate and plan their next phase.
Software is nothing like the commodities that Marx focused on. It seems reasonable that any expression of Marx's ideology that grows out of an economy based on software will differ. Perhaps it does it a disservice to call it communism. I'll need to look at these alternative economies to see what I think.
***
One of the thinkers who inspired Marx was Pierre-Joseph Proudhon who is best know by his saying that property is theft. In his essay "What is Property?" he makes a distinction between property owned but fallow versus property that is in productive use which he calls possession. That distinction reminds me of a problem that Google is facing in trying to digitize books. There are a great many books that are long out of print but still have active copyrights. The owner of that right can block the publication in any form. There is something that strikes me as inherently wrong to own something for the sole purpose of preventing anyone else from benefiting from it. If it is frictional in the sense that it is under current negotiation, then it is merely a strategy and a short-term dislocation. But if the owner is unknown or beyond negotiation, then the information is available in the limited number of books that exist but not readily available. The inevitable consequence of this is rampant copyright infringement for a popular item and the complete loss of the information from sources that no longer exist. This becomes a form of information rot. I rather admire Google for continuing to scan the books that fall into this category since they are actually performing a public good by ensuring the information will never be lost to theft or fire even while the owner may block the distribution.
You cannot look at FLOSS for long before seeing the communal aspect of these projects. Most recently the question was posed on Quora and I posted a lengthy answer there. (http://www.quora.com/Is-free-open-source-software-communist/answer/Dale-Fletter). I also answered a different question that I see as closely related having to do with how FLOSS has impacted commercial software development (http://www.quora.com/Software-Engineering/What-is-the-impact-of-the-open-sourcing-philosophy-on-proprietary-closed-software/answer/Dale-Fletter). Since that forum does not reward deep intellectualism and since this journal is my primary data base of ideas, I will try to repeat or improve my answer there.
A topic of discussion for the early economists was the tragedy of the commons. Since each person is naturally inclined to consume from the commons and make no contribution, this is a problem in a laissez-faire economy. (it is personally disturbing to me how little the current political parties that embrace libertarianism adequately deal with this fundamental problem). What I see in the current FLOSS market looks surprisingly like a reverse issue to the tragedy of the commons, let's call it the gift of the commons. In the FLOSS market consumption of the commons does not diminish it in any significant way. Yet because of the relationship people have with the commons, they are inclined to contribute to it leading to an increase in its value to everyone. This is clearly a way in which the assets are held in common for the good of everyone. It is also clear that many of these assets provide a means of production for many of the users of the commons. This forces the question, is this a form of communism?
To help me understand the question, I needed to put aside my own prejudices about communism and chose to educate myself on the source of much of its intellectual underpinnings in Karl Marx. The book I chose to read first is Karl Marx by Isaiah Berlin. I first tried to read The Capital/Das Kapital but abandoned it since his prose is painful and the progression of his ideas is glacial for a modern reader. The other advantage of Mr. Berlin's history is the cultural and intellectual context and the critical nature of his reporting. I highly recommend the book.
Marx had a deeply held point of view that has been largely debunked by the developments of the 20th century. Therefore his theory about class warfare and the inevitable fall of capitalism makes no sense any longer. However his early analysis of capitalism is surprisingly fresh and modern in its insight, if not always completely original. In my opinion, he was an empiricist, he believed that capitalism had inherent defects that were inimical to the inherent rewards of work and that without leavening, capitalism could not survive. I believe the history of the late 19th and all of the 20th century have proven this thesis to my satisfaction despite the current debate. What I find enthralling is how he seems to capture the spirit of many software engineers who contribute to FLOSS. There seem to be many motivations in their work and Marx, for me, seems to offer some insight into this emerging market. It is his intention to use a scientific method that includes economics and the other social sciences to observe, record, discuss, explain and theorize about what he saw as a model for the analysis of FLOSS.
Regarding qualitative analysis, Berlin observes, "This command to look for the most vivid expression of the universal in the particular, the concrete, the differentiated, the individual, to emulate the art and the realism of the biographer and the painter rather than the photographer and the statistician, is the peculiar legacy of German historicism." As I look at FLOSS, I intend to follow this command, at least for now.
While the broader concept of class means something very different today than it did at the time of Marx, let me first make some observations about class relative to FLOSS. Communication mediated by the software repositories created for FLOSS removed almost all traces of class that might intrude from outside. Many people involved do so anonymously and provide no meaningful picture of themselves outside of the project. This provides an opportunity for people to recreate themselves in this sphere. Coupled with the staunch support for meritocracy, someone with no power, status, or obvious class affiliation outside of the project could rise to the level of contributor. (it looks like anonymous contributors with commit rights don't exist in Apache but that needs more research). Beyond the hierarchy that exists due to this meritocracy, there does not seem to be any inherent class structure, at least within the confines of a project. Without a class structure, I don't see where any class friction can exist.
As I already observed, the commons is not diminished by the copying of the software. Also the project imposes no coercion for contribution. This is perhaps the most pure expression of the communist maxim of "from each according to their ability, to each according to their needs". (I note that the phrase, while popularized by Marx owes its origin to Louis Blanc). Of the abilities that contribute to the projects, there are many. Some have very fundamental needs to fix the errors in these machines to keep them running for the enterprises that are important to them. There are visionaries who pursue new features with an artistic zeal. Some fall in love (eroticize) the product and take a proprietary interest in making it the best possible product in the same way that Pygmalion created his beauty. The lack of a centralized plan would seem to diminish the utility of the final product but that is difficult to see in many cases.
Much has been written about the alienating effect of monads slaving over keyboards. Perhaps a motivation for contributors is the sense of belonging that active participation in a project community brings.
One of the aspects of FLOSS that most strikes me is that the utility of the projects does not cover the universe of software uniformly. There is a decided bent toward tools and utilities versus consumer products and other products that do not have well trained individuals as their primary consumers. By this I am talking about the preponderance of languages, web development and web deployment tools, databases and other tools of the trade. From the operating system to the creation of an industrial grade online service, it is possible to avoid paying a corporation any licensing fees. I am not aware of any period of human history when the tools of production have been so freely available. This represents another basic Marxist maxim that the workers should own the means of production. We now have an entire generation of web developers who are created significant value using the tools from the commons. It is their enlightened self-interest which causes them to contribute so as to further rationalize or extend these tools. Some even find ways to tweak the tools to create new market opportunities for themselves and garner personal rewards by bringing this value to market before anyone else.
It is the interplay between the commons and the for-profit marketplace that causes many people to question the label of communism. They call it a "gift-economy" or some other such label. What distinctions are they trying to paint? I still have much research to do in the area of alternative economies, in particular those related to the gift economy. However I am going to indulge my going in positions.
Wikipedia talks about how early file-sharing was a form of gift-exchange that fostered a sense of community. I'm not buying that. FLOSS has a very specific aspect that cannot be seen in music or most forms of art. When I buy a song, I now have a static object which will not change during the time it is of interest to me. Contrast that with a piece of complex software like an operating system. The utility of that download may last for a period of some years. However if it has become part of a larger system, I will not be inclined to abandon my investment of time in that larger system once that component is no longer completely compatible with the dynamic environment in which it exists. It is for this reason that large complex software has a value chain that includes periodic updates. And it is exactly this value chain that FLOSS most brilliantly fulfills. The collective work of the various parties who attach to that value chain ensure that the product is dynamic and continually adapting to its environment. As I become aware of new functionality that must be added to the version I have, I have some assurance that this project will have organically anticipated that need and already provided for it. Even if I am the first, there will be others who will benefit from what I may be forced to do as a matter of personal need. My contribution builds goodwill and community as I discuss my need with others who have the same or similar needs.
While I reject the idea of music file sharing as being similar to FLOSS as a form of gift economy, I completely agree that this community building is an inherent part of the FLOSS experience. Especially in their formative stages, FLOSS projects have a relatively small number of contributors. The inherent communication among these contributors creates a sense of personal intimacy that build community bonds. Trust grows. Shared context grows. Often new ideas sponaneously emerge from the discussion in one project that spawn another and a new project is born.
Another aspect of FLOSS that I find in Marx's writing has to do with the basic notion of work. In the traditional Theory X of work, an organization must provide incentives to work. Without them, people will be inclined to not produce. Both Marx and then later Theory Y suggest that work has intrinsic fulfillment. Taken with Maslow's hierarchy of needs, it appears that FLOSS attracts people who gain significant rewards from the support they give to FLOSS. What must be explored is to what extent this interacts with other forces to enable that. For example, if software developers who are most active in FLOSS are being paid by their employers to contribute, can we be assured that this has achieved some form of market stability? Software engineering salaries are still relatively high but they have begun to show some signs of market volatility as foreign countries have shown their ability to compete for this labor. There can be no doubt that some aspects of software engineering will become less financially rewarding in the future. Will this lead to a downturn in the FLOSS contribution?
Another interplay with FLOSS is those developers who were fortunate enough to have a financial success with an earlier product and now use FLOSS as an incubator for a new idea. Clearly anyone who has become independently wealthy does not represent a stable vision for the future of FLOSS.
FLOSS may become a proving ground for young talent. People in school or recently out who are still supported can afford to invest significant time contributing to a project of their choice. Is it possible FLOSS will become a form of Peace Corps where the young become apprenticed and learn their trade while simultaneously provide some societal good?
Modern economic thought does not see the world in the kind of binary fashion that was prevalent in the 1950s. Modern western economies are mixed with elements of both capitalism and socialism mixed. I cannot see any reason why there cannot be stable islands of communism that coexist in our economy. There are many utopian communities that have existed side-by-side for many years. Both models of economies seem flexible enough to allow for mutual coexistence.
The final point I see in FLOSS is the force of idealism and youthful optimism. Virtually all valley jobs involve a certain amount of kool-aid drinking. The most pure forms of capitalism involve a quasi-warfare mentality of competition in the marketplace. But just as effectively, you see many young people (and some older folks too) who become committed to an idealistic path that stands in stark opposition to the free-market capitalism. FLOSS seems to draw from this pool of talent as well. Perhaps it even offers some solace from the brutality of an unbridled capitalist environment and a place where people can go to mentally recuperate and plan their next phase.
Software is nothing like the commodities that Marx focused on. It seems reasonable that any expression of Marx's ideology that grows out of an economy based on software will differ. Perhaps it does it a disservice to call it communism. I'll need to look at these alternative economies to see what I think.
***
One of the thinkers who inspired Marx was Pierre-Joseph Proudhon who is best know by his saying that property is theft. In his essay "What is Property?" he makes a distinction between property owned but fallow versus property that is in productive use which he calls possession. That distinction reminds me of a problem that Google is facing in trying to digitize books. There are a great many books that are long out of print but still have active copyrights. The owner of that right can block the publication in any form. There is something that strikes me as inherently wrong to own something for the sole purpose of preventing anyone else from benefiting from it. If it is frictional in the sense that it is under current negotiation, then it is merely a strategy and a short-term dislocation. But if the owner is unknown or beyond negotiation, then the information is available in the limited number of books that exist but not readily available. The inevitable consequence of this is rampant copyright infringement for a popular item and the complete loss of the information from sources that no longer exist. This becomes a form of information rot. I rather admire Google for continuing to scan the books that fall into this category since they are actually performing a public good by ensuring the information will never be lost to theft or fire even while the owner may block the distribution.
Thursday, June 14, 2012
What is a computational object?
In this sense, externalizing ideas is not a matter of emptying out the mind but of actively reconstructing
it, forming new associations, and expressing concepts in external representations while lessening
the cognitive load required for remembering them: “Externalization produces a record of our mental
efforts, one that is ‘outside us’ rather than vaguely ‘in memory’. ... It relieves us in some measure from the always difficult task of ‘thinking about our own thoughts’ while often accomplishing the same end. It embodies our thoughts and intentions in a form more accessible to reflective efforts.” ((Bruner, 1996), p. 23)
http://l3d.cs.colorado.edu/~gerhard/papers/fi_ost-final.pdf
The computational viewpoint is directly concerned with the distribution of processing but not with the interaction mechanisms that enable distribution to occur. The computational specification decomposes the system into computational objects performing individual functions and interacting at interfaces. It thus provides the basis for decisions on how to distribute the jobs to be done, because objects can be located independently assuming communications mechanisms can be defined in the engineering specification to support the behaviour at the interfaces to those objects.
The heart of the computational language is the computational object model, which constrains the computational specification by defining:
- the form of interface an object can have;
- the way that interfaces can be bound and the forms of interaction that can take place at them;
- the actions an object can perform, in particular the creation of new objects and interfaces, and the establishment of bindings.
The computational object model provides the basis for ensuring consistency between different engineering and technology specifications (including programming languages and communication mechanisms) since they must be consistent with the same computational object model. This consistency allows open interworking and portability of components in the resulting implementation.
The computational language enables the specifier to model constraints on the distribution of an application (in terms of environment contracts associated with individual interfaces and interface bindings of computational objects) without specifying the actual degree of distribution in the computational specification; this latter is specified in the engineering and technology specifications. This ensures that the computational specification of an application is not based on any unstated assumptions affecting the distribution of engineering and technology objects. Because of this, the configuration and degree of distribution of the hardware on which ODP applications are run can easily be altered, subject to the stated environment constraints, without having a major impact on the application software.
http://www.rm-odp.net/
Computational objects in object-oriented data models, Authors: Jianhua Zhu, David Maier
Computational object recognition: a biologically motivated approach, Authors: Tim C. Kietzmann, Sascha Lange, Martin Riedmiller
Heekyoung Jung, Youngsuk L. Altieri, and Jeffrey Bardzell. 2010. Computational objects and expressive forms: a design exploration. In Proceedings of the 28th of the international conference extended abstracts on Human factors in computing systems (CHI EA '10). ACM, New York, NY, USA, 3433-3438. DOI=10.1145/1753846.1753997 http://doi.acm.org/10.1145/1753846.1753997
Form and the computational object, by Ramia Mazé, Johan Redström
Temporal Computational Objects: A Process for Dynamic Surface Generation, Authors: Kurt W. Swanson, Kenneth A. Brakke and David E. Breen
Simulating an Economy with Smithian Production: Division of Labor as a Computational Object
By Roger A. McCain, http://faculty.lebow.drexel.edu/McCainR/top/eco/wps/RAMcCEastern.pdf
The Distributed Interactive Object Substrate (DIOS) forms the back-end of DISCOVER and is composed of two major components: (1) Interaction Objects that are co-located with computational objects and encapsulate sensors and actuators, and (2) A hierarchical control network that connects these objects with different interaction agents. http://nsfcac.rutgers.edu/TASSL/Projects/DISCOVER/DIOS/DIOS.html
Subscribe to:
Posts (Atom)