open source as unpleasant subculture
A /. story led me to the archives of the Linux kernel mailing list. In this I am reminded of one personal reason I have never been attracted to the Free Software or Open Source ideology. It requires a major lifestyle commitment which involves the company of unpleasant people, as a quick browse through those archives will demonstrate.
The promise of making the source code for software freely available is easy modification. That is, given that software often needs to be customized to meet the requirements of a particular project, a wealth of free software should make accomplishing any project's goals easier, because one can modify something that is already close to the requirements instead of starting from scratch.
The reality is different. When combining small free tools for simple functions, like adding simple forms to a web site, and given a good initial tool selection, then one can often apply this method and quickly integrate some simple command-line-based tools, or perl or Python modules, without a great deal of startup time or lifestyle commitment to the project. Modifying the large open source projects where customization presents interesting possibilities, such as the Linux or Darwin kernel, the GCC compiler, or the Mozilla browser, however, is a very different story. They are not particularly penetrable without help, and it can be very misleading to try to understand them by reading the code oneself or using whatever sparse documentation may be available. They require a lifestyle commitment and subculture participation.
Large open source systems are sprawling and Frankensteinian, and one is going to need the guidance of the mailing list and chat room to get anywhere with them. For instance, there may be a paper on memory allocation in the system (a basic service required by almost all software programs, but often different from program to program). This document might well describe only a hoped-for future direction, which was never implemented after the person left the project. Going through the source and looking for memory allocation might fail to reveal that there are actually five different memory allocators, all representing partially tuned attempts to deal with different aspects of the problem, and scattered throughout the code controlled by a set of macro expansions. Of course, the community knows this already, and therein lies the problem.
Popping into a chat room to get an answer is really not that odious a responsibility, in theory. In practice, though, one has to actually integrate into the community, spending long hours bartering for help, and trying to make the best of dealing with unpleasant and undersocialized people who often have little social status or acceptance outside the community. The level of discourse ranges from abusive to actionable. Simply getting straight answers is difficult. Ordinary technical issues become the objects of gargantuan philosophical and religious debates, usually uninformed by any reading in the relevant computer science literature. Heaven forfend that someone should drop in with a well-meaning technical question that has become a hot-button issue for the insular software-project subculture, or wishing to help solve a problem that has been vehemently denied for years.
Every free project community I've encountered so far is run as a fiefdom and partakes of a highly polarized insider-outsider dynamic. Abuse is taken for granted and encouraged toward newbies, as a kind of hazing that establishes loyalty to the group. The prize is the sanctioned ability to give more abuse than you receive. These seats are highly coveted and it is assumed that newbies will be contenders, so abusing newbies and driving them away serves a function beyond initiatory bonding as well. The best way to take them is to be willing to soak up a lot of abuse and to spend sixteen hours a day glued to every relevant chat room, mailing list, bug database and cvs archive, waiting for some justification for your next tantrum. Take another look at the Linux Kernel mailing list, reportedly one of the most functional communities in open source. It runs about 250 messages a day. This is all these people do.
Between the time drain and the unpleasant company, making a significant contribution to free software and open source would require a kind of lifestyle commitment that I am not prepared to make. Having an ordinary software engineering job already leaves my life revolving around software more than I would like it to. I don't have time to invest in an online apprenticeship in a "free" project that wants to eat months of my life before it will give me the time of day. In my profession, I don't have to. I'm not a newbie at more than twenty years experience. The people hiring me know my references and background and they treat me with professional respect and collegiality. If I have to spend a large portion of my life on software, I'd like to do it in an atmosphere of decorum, not in a chat room getting jeered at by sixteen-year-old aspirants to a retro cyberculture dream world that never existed. I'm a software professional, not a software nerd. The center of my life is elsewhere, and status in such an insular and unpleasant community has no appeal for me.
The promise of making the source code for software freely available is easy modification. That is, given that software often needs to be customized to meet the requirements of a particular project, a wealth of free software should make accomplishing any project's goals easier, because one can modify something that is already close to the requirements instead of starting from scratch.
The reality is different. When combining small free tools for simple functions, like adding simple forms to a web site, and given a good initial tool selection, then one can often apply this method and quickly integrate some simple command-line-based tools, or perl or Python modules, without a great deal of startup time or lifestyle commitment to the project. Modifying the large open source projects where customization presents interesting possibilities, such as the Linux or Darwin kernel, the GCC compiler, or the Mozilla browser, however, is a very different story. They are not particularly penetrable without help, and it can be very misleading to try to understand them by reading the code oneself or using whatever sparse documentation may be available. They require a lifestyle commitment and subculture participation.
Large open source systems are sprawling and Frankensteinian, and one is going to need the guidance of the mailing list and chat room to get anywhere with them. For instance, there may be a paper on memory allocation in the system (a basic service required by almost all software programs, but often different from program to program). This document might well describe only a hoped-for future direction, which was never implemented after the person left the project. Going through the source and looking for memory allocation might fail to reveal that there are actually five different memory allocators, all representing partially tuned attempts to deal with different aspects of the problem, and scattered throughout the code controlled by a set of macro expansions. Of course, the community knows this already, and therein lies the problem.
Popping into a chat room to get an answer is really not that odious a responsibility, in theory. In practice, though, one has to actually integrate into the community, spending long hours bartering for help, and trying to make the best of dealing with unpleasant and undersocialized people who often have little social status or acceptance outside the community. The level of discourse ranges from abusive to actionable. Simply getting straight answers is difficult. Ordinary technical issues become the objects of gargantuan philosophical and religious debates, usually uninformed by any reading in the relevant computer science literature. Heaven forfend that someone should drop in with a well-meaning technical question that has become a hot-button issue for the insular software-project subculture, or wishing to help solve a problem that has been vehemently denied for years.
Every free project community I've encountered so far is run as a fiefdom and partakes of a highly polarized insider-outsider dynamic. Abuse is taken for granted and encouraged toward newbies, as a kind of hazing that establishes loyalty to the group. The prize is the sanctioned ability to give more abuse than you receive. These seats are highly coveted and it is assumed that newbies will be contenders, so abusing newbies and driving them away serves a function beyond initiatory bonding as well. The best way to take them is to be willing to soak up a lot of abuse and to spend sixteen hours a day glued to every relevant chat room, mailing list, bug database and cvs archive, waiting for some justification for your next tantrum. Take another look at the Linux Kernel mailing list, reportedly one of the most functional communities in open source. It runs about 250 messages a day. This is all these people do.
Between the time drain and the unpleasant company, making a significant contribution to free software and open source would require a kind of lifestyle commitment that I am not prepared to make. Having an ordinary software engineering job already leaves my life revolving around software more than I would like it to. I don't have time to invest in an online apprenticeship in a "free" project that wants to eat months of my life before it will give me the time of day. In my profession, I don't have to. I'm not a newbie at more than twenty years experience. The people hiring me know my references and background and they treat me with professional respect and collegiality. If I have to spend a large portion of my life on software, I'd like to do it in an atmosphere of decorum, not in a chat room getting jeered at by sixteen-year-old aspirants to a retro cyberculture dream world that never existed. I'm a software professional, not a software nerd. The center of my life is elsewhere, and status in such an insular and unpleasant community has no appeal for me.