By Dr. Nikolai Bezroukov
Version 1.0 (March, 2011, with minor corrections June 2017)
Copyright 2010-2011, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.
In the vision of Software Realists software development of complex systems requires both organization and talent of individual contributors. And that there is no magic bullet to solve complex software development problems. It is also the belief that programmers like all humans have weaknesses and, while they can act altruistically, they need certain standard of living to pursue their craft. Software development is hard but it is maintenance that breaks the camel back. Most open source developers can altruistically maintain their project for three-five years after which the amount of thankless labor and fatigue extract its toll and the project is abandoned. That does not mean that everybody is driven only by self-interest (neoliberal point of view, which is way too simplistic). People are complex creatures. The desire for recognition is a powerful motivator and can drive many to contribute in addition or instead of pure altruistically motives. But it can't last forever. Rephrasing Oscar Wilde we can say that motivation to contribute to open source is seldom pure and never simple. I would add that they, in addition, to that are seldom long lasting. the problem of succession, when the original developer lost interest in the project is acute and doomed many promising project. Way too often, nobody can pick up the fallen flag in this battle. Open Solaris, System Imager are two such examples.
The Software Idealist school (both in its Stallmanism and Raymondism incarnations) holds that mankind in general and programmers in particular has not yet achieved their full moral potential, and that they are (at least in principle) perfectible if guided by wonderful new software development ideology. Foolish and immoral choices inherent in the creation of proprietary software explains the all the evils of the existing software world and revolution was needed and actually already came in the form of either free software movement or its less pure form called open source software movement. Both major Software Idealism schools rely on volunteer labor of programmers connected via Internet to produce immortal gems of software wisdom that will crush proprietary software developers like cockroaches. The question who pays those volunteer developers simply not arise.
In Software Idealism worldview, whether purely moral incentive actually work in a long run or not and what will happen when Linus Torvalds will become yet another retired dot-com multimillionaire with his own yacht is irrelevant to the achievement of true software justice, justice for all. This utopian view holds that the volunteer programmer potential is immense in a globalized world, and can do everything including improving human nature that should get rid of those outdated economic rewards for software development and be satisfied working part time in McDonalds in order to be able to participate in the movement.
So the Software Idealism vision promotes pursuit of the high moral ground of software freedom which somehow automatically guarantee the best software solutions. At the end of the day new liberated men should all storm this evil Bastille of software oppression which is of course Microsoft and dance on its ruins. Sometimes in their enthusiasm they can attack other sinful old fashioned proprietary software vendors instead of Microsoft. Until opening Solaris (and even after that) sometimes their target was Sun.
And if the unwashed masses who corrupt their soils by using Windows are slow in catching on, then it is the role of the intellectual vanguard (the keepers of programming craft who in Eastern Europe might be called "programming intelligentsia") to lead them -- even if in the short run, the masses can be unhappy with the results because they might not be able to use full capabilities of their laptops, cameras or scanners. In general Software Idealists think that higher moral considerations should guide us and that those consideration somehow guarantee creation of a better software, the software which is as perfect as it is free.
My research considers open source not only as a programming methodology with some moral overtones, but also as a scientific-ideological entity. George Orwell remains our contemporary and his writings are as current as writings just published this year despite the fact that he died in 1950. His essay "Politics and the English Language" ought to be read by everybody who is interesting is OSS. "The great enemy of clear language is insincerity," he wrote. "When there is a gap between one's real and one's declared aims, one turns as it were instinctively to long words and exhausted idioms, like a cuttlefish squirting out ink." He also aptly defined inescapability from OSS politics
"In our age, there is no such thing as 'keeping out of politics.' All issues are political issues, and politics itself is a mass of lies, evasions, folly, hatred and schizophrenia,"
Orwell wrote. Earlier in the essay he said,
"In our time, political speech and writing are largely the defense of the indefensible."
That means that even things quite remote from mainstream political issues, such as open source software are still driven by ideology. In my papers I argued for a blurriness of the boundaries between programming topics and political topics of leading open source propagandists such as Richard Stallman (RMS) or Eric Raymond (ESR). I also demonstrated that open source advocacy created a space where programming concepts and terms transformed into political and ideological ones, and vice versa. This is especially visible on the example of GPL (Social Roots, Complexity and Never Ending Process of Interpretation of GPL )
Slightly simplifying there are two contrasting ideologies of programming:
Let's first discuss software realism.
Still open source software developers perform a vital function in "software ecology" -- they provide a channel for knowledge exchange, not only a software product. And this is equally important. Any successful open source software project that serves as a channel of knowledge exchange. But if this is true, like for any academic project, it is important that nobody became rich in the process. That complicates the picture. And that's why attempts to commercialize open source software project often is met with open hostility. We can say that "software realism" views is an extrapolation of their set of views such as "all software sucks", "software development is hard", "there is no silver bullet" and success is not guaranteed; most project are over budget and take twice as long as they were planned to take. Views that stems from famous book by Frederick Brooks The Mythical Man-Month aka TMMM (1975)
In slightly tragic worldview of " Software Realism" the software development is inherently very hard and often underappreciated craft that requires special, pretty rare, talent and huge, and for a "solo performer" huge, almost superhuman dedication both in time and effort. Where like in art the success amount of efforts does not guaranteed any level of success, which often is determined by factors other then software quality and development talent( although the latter is a prerequisite ). It is not guaranteed even for very talented and dedicated developers. For example, software can be well ahead of its time, of face entrenched competitors, which already acquired the critical mass of "eyeballs".
People with this talent like talented sport stars (for example, top tennis players, or ice ballet dancers) risk their health while they are young creating short living, but tremendously complex artifacts (large software systems are probably the most complex systems even created by humans) and for this reason should be remunerated accordingly. It is important to understand that like in case of artists creating paintings on the sand beach, programmers creation are often short-lived and the new wave of hardware often wipes them clean. For example, who now remembers the creators of PL/1 optimizing and debugging compilers, the compilers that were real breakthrough in many areas of complier writing art and in comparison with which many modern compliers still look like junk despite the fact that they were written 30 years ago.
That's why either as moral obligation, or as "superior programming methodology" completely "pro bono" development is not panacea. Both types of development should co-exist in healthy software ecosystem. And there is nothing tragic, if open source developers switch to closed source development to survive, or vice versa -- commercial product that lost market viability are open sourced to help the codebase to survive. One obvious problem with open source that unless "appropriated" by commercial companies (Red Hat , Suse, Google) or special foundations (Mozilla), it often have a limited lifespan. It is definitely is not suitable for all types of programs and first of all programs for which the particular programmer cannot be simultaneously a natural user (this is the case for operating systems, compilers, editors and many other programming tools) as well as for programs above and beyond certain level of complexity, when availability of the source code means much less. Complex open source projects are actually semi-closed by definition, as to understand the code base is almost impossible for mere mortals.
At the same time some software survives for a long time after being abandoned by the original developers (Sun SGE is one example). Even some closed source Microsoft products (for example, Frontpage and FoxPro) survived for a long time after being abandoned by the company. So plethora of new versions is often not needed for continuing viability of software. Minimal efforts of correction of bugs and security vulnerabilities, as well as portability issues caused by new version of OS might be enough. Attempts to "scratch your itch" by unqualified but enthusiastic developers can destroy the software. And often it does. Wanna-be who assumed the role after the original developer bailed out often do not understand the project well enough and thus can't maintain the conceptual integrity. They often engages in "Christmas tree" style enhancements, which later dooms the project.
In other words, Software Realists see that due to immense complexity of those artifacts "all software sucks." It is just that some software sucks less. But even this is not automatic. It can be proprietary software, it can be free software -- but the quality mostly depends on the talent of the creators, not so much on a particular path of development, or underling ideology (which, by the way, can be completely wrong: Soviets invented quite a few new technologies and managed to launch the first man into space). Thus, in view of Software Realists school the perfection of software is unachievable and old good Unix with its classic codebase might sometimes be preferable to new Turks be it Windows, or Linux. That does not mean that Linux or Windows codebase is all crap. That just means that they are just reached the stage of overcomplexity, like many other OSes in a long historical line of such systems. In some areas they are still much better then competition, in some worse, but none has the monopoly on innovation (actually Linux is a pretty conservative kernel despite a radical ideology behind it). And overcomplexity bites equally strongly both Microsoft and linux developers. with Windows 8 Microsoft partially destroyed conceptual integrity of windows, if such ever existed, and in this sense it one step forward two steps back after Windows 7. Similarly RHEL 7 with its systemd mess is one step forward two steps back in comparison with RHEL 6.
Software Realists are unconvinced by claims of open source superiority in general and linux superiority over alternatives such as Solaris in particular and want to see hard facts. Furthermore, history guided them that the proper tradeoffs between different subsystems of OSes can be ironed out only via long, expensive and painful process that requires talented managers, programmers and testers who are ready to sacrifices their health for the success of their creation. The real art requires sacrifices and it is better when such sacrifices are properly remunerated, although stories of talented artists who died in poverty are nothing new.
Because real talents are rare, and even more rarely can control the creation of complex software projects, good software like art masterpieces is a very expensive thing. Replication makes obtaining copies almost zero cost, but it does not make development cheaper. Software realism school presuppose that modern software is almost always crippled, is always a compromise between the demands of the talent and demands of the marketplace. And, that, paradoxically, former commercial software that was for some reason was open sourced by their creator can be superior to the software which started as an open source project from the very beginning.
At the same time development goals for open source software should be different and attempt to match closed source software is often a bad strategy. keeping simplicity is more important for long term viability of open source, then matching feature by feature of commercial software that perform the same of similar functions. The slogan "Keep it simple stupid" is really the key to avoiding abandonware status in three to five years. Although even it does not provide any guarantee. Still in order for new developers to pick up the fallen flag, the codebase should be more or less understandable without the necessary of spending months poking around the existing code. Here Unix with it philosophy of simple tools, that can be combined to perform a particular task is really important. But more is needed.
Creation of any complex software systems ( closed or open source ) can benefit from existence of a formal software development organization and incentives (direct or indirect) as those factors help to prolong the drive beyond the usual limits defined by initial spark of interest and drive to implement some kind of programming vision (see The Mythical Man-Month).
In the absence of such organization, open source projects, at least, at initial stages, are a very lonely sport. Early users community can help, but it also can harm distracting developer from the key goals. At best it is a limited substitute. Even at mature stages the group of key developers is usually small, often with one lead developer doing the lion share of work. Simply because there is no place for "Mongol horde" approach in programming in general, and for complex software projects in particular. Also often because for the key developer the project is a matter of pride, less so for developers who come later on.
Software Realists see the evils of the software world as given and derived from the limited and unhappy choices available, given the inherent moral and intellectual limitations of human beings, as well as existing hardware and demands for compatibility with pre-existing environment. The first of those factors means the switches from altruism to greed and back are not that uncommon among open source software developers. And with growing success of the project the temptation of greed are considerable and can't be discounted. So using academic style norms to judge what is open source development and what is just an imitation is important as they can prevent worst excesses, and are polished by thousand year history of academic science. Here, in a fundamental way, it is important to have a safeguards, preventing enrichment of the few at the expense of many. Switch to close source development is a lessee evil in such cases, then the corruption of the community. Close source developers can contribute and often contribute to open source projects. As for the problem of reusing open source code, the acknowledgement in derivative works is the only requirement and it is mostly a moral one as reflected in the initial version of BSD license.
Another key point is that "overcomplexity breeds greed", as after some point it is simply impractical to developers to continue the project on "pro bono" basis. This means the key importance of keeping open source software simple and the desirability of a formal way to fork open source codebase into closed source project at least for the developers of the software.
Software realists contribute to open source projects not because they see them superior to commercially developed software, but because they consider them an important part of software ecosystem, the part that requires support and nourishment and helps to keep closed source software developers honest. It is a extremely important countervailing force that has value of its own, independently whether particular open source program is superior to similar closed source program or not, the availability of open source codebase make it more suitable for some purposes, for example in education where the availability of source code can often compensates for real or perceived shortcomings. They view open source development as a special type of academic research that has similar set of motivations, similar risks and reward structure. The mere availability of open source alternatives positively changes the dynamic of software development, both for commercial projects and other open source projects. Also availability of the source code is crucial for some purposes, for example in education and often compensates for real or perceived shortcomings. And, as such, needs to be supported by the society and the state.
|Software realists contribute to open source projects not because they see them superior to commercially developed software, but because they consider them an important part of software ecosystem. They view open source development as a special type of academic research that has similar set of motivations, similar risks and reward structure. And, as such, needs to be supported by the society and the state.|
For me, the tension between private and public domains in open source software development looks very similar to what is happening within the university research. Goals of private companies and universities are radically different. Private companies put profit first and have their first primary goal in maximizing profits through controlling and owning resources that constitute a proprietary advantage allowing to succeed them on the market place. Universities traditionally put first the developing of scientific commons although under neoliberalism this role recently became less pronounced and more perverted. Neoliberalism brought with it excessive stress on commercializing of everything with the university system. The Western adage that "the habit does not make the monk" is fully applicable to open source developers. Like there are corrupted, dishonest scientists, there are corrupt and dishonest open source developers.
Like academic research results real open source development is inherently "pro bono". It is a gift to humanity. Gift is a gift and should not have strings attached. Still developers of derivatives should voluntarily subscribe to academic ethic in which the person reusing somebody else code needs to acknowledge source and this is an important moral obligation imposed by original BSD license, which for this particular reason, I consider preferable to GPL.
Crooked Timber points to an interesting speech by Robert Hughes about the Royal Academy, and by extension the idea of a professional society in general. I think in the Unix Renaissance and open source software you can see some similar themes.
I believe it's not just desirable but culturally necessary that England should have a great institution through which the opinions of artists about artistic value can be crystallized and seen, there on the wall, unpressured by market politics: and the best existing candidate for such an institution is a revitalized Royal Academy, which always was dedicated to contemporary art.
Part of the Academy's mission was to teach. It still should be. In that regard, the Academy has to be exemplary: not a kindergarten, but a place that upholds the primacy of difficult and demanding skills that leak from a culture and are lost unless they are incessantly taught to those who want to have them. And those people are always in a minority. Necessarily. Exceptions have to be.
In software realists view open source development is not just an ideological issue per se. It is also a part of the academic culture with such prominent figures from academia as Donald Knuth firmly belonging to this tradition (Knuth open sourced TeX before the term was available). In this particular sense, we can talk about classic Unix culture in the terms similar to Roman and Greek cultures that were the cornerstones of Western civilization. And we can lament, how few contemporary Linux developers understand it ;-).
This analogy suggest that commercialization of open source projects are similar to commercialization of research results and there is nothing uncommon if at some stage the project that started as open source is converted to proprietary model. And vise versa, the project that was proprietary, close source model at some stage can be opened to prevent dying of a valuable codebase. So the method of development is not absolute, and whatever help talented people to drive the ball further is good. But hypocrisy when formally open source project became de-facto closed source (and is milked as such) is bad. It is more honest at some point to separate them and provide payable closed source version and, if there is desire and capability, free open source version (actually the danger of 'stealing" for complex open source project proved to be minimal; there are not many cases of such behaviour because overcomplexity of the codebase automatically prevents reuse). Or simply fork two and devote some minimal effort on maintaining a stable open source version.
The key is software development is level of talent and here using popular American cliché "there is no replacement for displacement. " Talented people are productive in any development model, be it closed source or open source and can mix and match both quite easily (many talented programmers contribute to open source projects; I strongly recommend is as a antidote to detrimental effects of working in stiffing, bureaucratic environment which programmers need to endure in a typical IT environment of a large company; pursuing a post-graduate degree is another good antidote, but it requires more commitment).
The more complex programming system is, the higher role is the role of formal organization and the person who assumed the role of chief architect (in open source project this is always the initial developer who with the success of the project naturally moves to the role of chief architect). Launching a sizable open source project requires strong talent and compete dedication: generally you cannot be "half-pregnant" with complex program that have, say, tens of thousand lines of source code. And such 10*7 job that requires tremendous concentration can not be done of pro bono basis forever. All other activities suffer and passionate involvement in such project tends to downgrades the lifestyle to monk-style life with monotonous repeating sequence "computer-bed-computer". For example, long before Linus Torvalds became an attraction on various conferences he spend couple of years almost like a kermit and then half of the decade in the frantic pace close to that. Typically the initial enthusiasm that drives people to create those program evaporates pretty quickly, in several years. So, unless remuneration comes with the success, it is better if open source development is just a short initial stage in the career of talented developers. Then you either give up or commercialize the program. This is a valuable possibility to show the world the level of talent you have, to prove yourself. But this is not the only possibility and not always this is the best possibility. Open source version will remain as a testament of your contribution to the community. This fair tale of horde of volunteer developers maintaining a complex open source software project with a few exceptions remains neoliberal fairy tale. You need an organization for such things, as a minimum a foundation like Mozilla Foundation, or Linux foundation in case of Debian (Ian Murdock, the father of Debian, died at 42).
For sizable projects at mature stages the organization and remuneration issues comes to the front. That's why there is nothing wrong with adopting the second license and even converting the project into closed source project (the last open source codebase may, or may not, find new maintainers). Also importance of organization increases as more developers are involved: two-three developers can well work without any formal organization, but for larger team this is problematic. Strong egos typical for talented developers create conflicts and drain energy. And what is important to understand an illusive goal on which so much energy and time is/was spent might well be a mirage. In other words becoming full time dedicated open source developer entails substantial risks, especially high if you do not have funds for independent living, or have a family to support. Commercial programming career with all its shortcomings provides that. And the level of excitement is some commercial startups can match or exceed the level of excitement of creating you own program. As Jamie Zawinski put it:
There exist counterexamples to this, but in general, great things are accomplished by small groups of people who are driven, who have unity of purpose. The more people involved, the slower and stupider their union is.
And there's another factor involved, which is that you can divide our industry into two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company.
It is important to understand that, like in case of artists creating paintings on the sand beach, programmers creation are short-lived and the new wave of hardware often wipes them clean. For example, who now remembers the creators of PL/1 optimizing and debugging compilers, the compilers that were real breakthrough in many areas of complier writing art and in comparison with which some modern compliers still look like junk despite the fact that they were written 30 years after IBM's PL/1 compilers. The same is true about very interesting PL/C compiler developed at Cornell University. New technological wave came and magnificent sculptures made of sand were wiped clean. Similarly who now remembers the key contributors to the Linux kernel version 1.x ? Version 2.2? Version 2.4? And who was this guy Alan Cox?
In other words, software realists see that due to immense complexity of those artifacts all software sucks. It is just that some software sucks less. It can be proprietary software, in can be freeware, shareware or free software -- but the quality itself by-and-large depends of the talent of the creators, not so much on a particular ideology/methodology (which, by the way, can be completely wrong: Soviets invented quite a few new technologies and managed to launch the first man into space).
|Software realists see that all software sucks. It is just that some software sucks less. It can be proprietary software, in can be freeware, shareware or free software -- but quality depends of the talent of the creators, not so much on a particular ideology/methodology|
Thus, in view of Software Realists school, the perfection of software is unachievable and old good Unix/Linux with its classic codebase might sometimes be preferable to new Turks be it Windows or Red Hat 7.x ;-). They actually view Linux as kind of Windows of Unix world: system that achieved popularity more due to "worse is better" principle and the success of Intel hardware (driven BTW by the success of Microsoft ;-) then to technical superiority of architecture decisions made by Linus Torvalds and his team.
In no way Software Realists consider OS to be a sacred cow. It is just an instrument like a good compiler or good programming editor, although it exert more influence on the programmer and is a more important factor in determining the success or failure of large programming projects. Sometime Solaris 10 is the way to go, sometimes Windows, sometimes Mac OS, sometimes Linux (Web hosting is a nice example). Each OS has areas where it has advantages over competition and it depends on how important those areas are. If they are extremely important it make sense to switch OSes, otherwise it is often more productive to suffer from shortcomings and still use your primary OS, as learning a new OS in depth is a long, time-consuming process. For example many software realists use Windows as desktop because it the most popular, reasonably stable and has tremendous quantity of high quality inexpensive software. And you do not need to think about drivers necessary to drive you camera, webcam or scanner. By definition all new gadgets work on Windows. Life is too short to spend it on searching Google for suitable driver or recompiling the kernel. Even with all it security vulnerabilities.
In other words in no way Linus Torvalds and his distributed kernel development team stand heads above kernel developers for Solaris or FreeBSD, or Windows. Similarly in no way gcc is superior to Intel compiler, or Sun compiler, although it definitely has its strong points (and first of all tremendous portability). Actually as for kernel quality opposite is often true if you look at the technical metrics of Linux kernel and compare it with Windows and/or Solaris kernel without rose glasses of Raymondism or Stallmanism. Operating systems are now so complex and need to cover so many areas that it is just impossible to be No.1 in all areas. So each OS needs to give up some ground. And here no kernel development team structure, no programming methodology, no choice between closed and open source that can provide a magic bullet for the ultimate success. Only talent, dedication, and good timing can. For large project add to this equation an organization and the leader.
In other words Linux codebase is an interesting and welcome development, but Linux is just another "new kid on the block" that exists along with various flavors of BSD, and the functionality provided by Linux kernel has little new in comparison with old horses in this race like Solaris 10 or FreeBSD. The latter, like Linux, has zero price, so even in price Linux has strong competitors :-). So Linux is just another page in a long, more than half a century history of development of operating systems and might well at some point be superseded by new entries in a long historical line of such systems. Linus Torvalds is not immortal and troubles connected with the retirement of the "old guard' still awaits this OS.
That means that neither Windows nor Linux can't completely eliminate completion. And their popularity can't be explained strictly by technical merits, it happened not because of their technical superiority but also de to perfect timing (BSD software lawsuit) and other, mostly social, factors. And in this respect, all writings of Stallman and Raymond about moral or technological superiority of free/open source software are just nice, but not very convincing, myths. Like there is no replacement for displacement, there is no replacement for talent. And for example the fact that, say, product of Evil Empire called FrontPage compares pretty well any non-commercial alternative, or the fact that Windows in certain areas and in certain phases of its development can wipe (and did wiped) the floor with Linux (as happened during, so called, Mindcraft fiasco) is a fact that is difficult to disprove :-).
Stallmanism and Raymondism are nice myths. May be even useful myths, as the popularity of open source really helped developing nations to get a stack of software for which one does not need to pay and which they, at least theoretically, can enhance and maintain themselves. But still they are myths. In this respect number of followers of each doctrine means nothing: there is no truth in numbers, and humanity is long known for its ability to provide tremendous following for pretty stupid ideas. Popularity of high demand cults demonstrate this axiom very well.
But while providing free alternatives is a honorable act and in this respect both Free/Net/OpenBSD and Linux are commendable efforts, in no way charging some money for the program is immoral (which is the cornerstone of Stallmanism). And in no way, open source software development process always provides technologically superior solutions (which is the cornerstone of Raymondism). Actually in comparison with Solaris 10 on Intel, Linux kernel, while good and finally reasonably stable (after 20 years of development), does not look too impressive (see Solaris vs. Linux) . Nobody has the monopoly on development talent, monopoly on technological innovation, monopoly on high stability, or suitability for particular domain. There are talents in each camp.
In other words, software realists are unconvinced by claims of Linux superiority and want to see hard facts for each particular claim. Furthermore, history guided them that proper tradeoffs between different subsystems of OSes can be ironed out only via long, expensive and painful process that requires strong, highly paid managers, programmers and testers who are ready to sacrifices their health for the success of their creation. Degradation of architectural vision in Red Hat which resulted in adoption of systemd in version 7.x might play a bad joke with Linux.
But in any case the real art requires personal sacrifices, and it is simply better and more humane, when such sacrifices are properly remunerated, although stories of talented artists who died in poverty are nothing new. So Software Realists are not surprised that some (many?) open source projects are in perma-beta stage. They accept this situation as a fact of life. Often such projects simply do not have sufficient resources for development and testing.
Because real talents are rare, a really good software is a very expensive thing. Software realism school presuppose that modern software is almost always a compromise between the demands of the talent and demands of the marketplace. They understand, although do not approve, why programmers often cut corners in the design of the software, architectural integrity and/or interface. Being first is often very important for grabbing market share, and for large projects only substantial market share can sustain further development of the product. This is the devil's pact developers need to sign.
While rejecting open source fairy tales, software realists have deep respect for open source authors, including not only BSD, but also Linux programming ecosystem. They see all the warts, but still view it positively. Moreover they consider contribution to open source a useful activity for gifted corporate programmers and sysadmin, especially those who wish to escape for a couple hours a day or a week corporate bullshit and stiffing bureaucracy. In my view contributing under BSD license which requires acknowledgement of the original author for reuse and enhancements is more honest, but any license is acceptable. Nothing wrong with GPL if you like it. In any case, it is not necessary to expect miracles from open source or view it as a high moral ground to provide contribution to this important communal ecosystem that we all can benefit from, independently whether we are lovers or haters of GPL, bazaar model or both ;-)
|It is not necessary to expect miracles from open source or view it as a high moral ground to provide contribution to this important communal ecosystem that we all can benefit from, independently whether we are lovers or haters of GPL, bazaar model or both ;-).|
Even those red eyed open software enthusiasts are a useful part of ecosystem as by chanting "Linux is best, Linux is best" (substitute Linux with the name of your favorite product), they do provide stimulus for commercial programmers do better, revitalize the development process in the companies like Microsoft and provide some alternatives. Open source serves as an important countervailing force for commercial software development that helps prevent it from stagnation and overconcentration on profit margins ("software racket", which affect some open source developers, who sell maintenance contracts too; licensing of software or maintenance contract "per core" instead of "per socket" or per server is a sure sign ). In a way it helps to keep Microsoft, Oracle and other large commercial software development houses honest.
Internet dramatically improved the scope and volume of transfer of programming knowledge making it available even in distant countries. In a way knowledge of programming became so widespread that it can be considered a "new literacy" and the person who does not know any programming language cannot be considered literate in full meaning of this word in XXI century. This process happened independently and in parallel to the growth of popularity of open source development. Availability of eBooks and eBooks libraries signify qualitatively new level of programming (and not only programming) "knowledge exchange" infrastructure, a really democratic one. It is unclear what will come next, but now with all major programs existing in both open source and close source equivalents, the key question becomes not availability, but quality.
But in no way this democratization confirms the bazaar metaphor -- the neoliberal view on software development. We should not forget that programming, especially on high levels, is an art that requires special, rare talent. Bunch of low skilled enthusiasts can't replace one really talented developer. And, like great paintings, great programs can be created only by great artists. Talent, taste and style are more important factors that development model. Ugly program is an ugly program, and no programming methodology nothing can change that. Architectural blunders are architectural blunders, and open source model gives no protection from them. In other words a large and complex ugly open source program with severe architectural defects is not panacea. It is a disease. May be even worse then a similar in quality closed source program as it can seduce re-implementers into using wrong architectural decision driven by sheer availability of the codebase.
As Donald Knuth noted in his Turing lecture "Programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules." As in other crafts there is an aesthetic satisfaction in accomplishing something with limited tools. And the value of simplicity, the value of sticking to kiss principle should never be forgotten despite all the temptations of the marketplace. I think that creation of simple, elegant tools is the real essence of open source. As Knuth noted even tools that we are using to create programs should a pleasure to use, instead of providing something we have to fight with. And we need to select the best tools that enable us to write better programs be they open or close source. The tools that enable us to view ourselves as masters of the special craft and create beautiful artifacts as reflected in famous Donald Knuth quote: " A programmer who subconsciously views himself as an artist will enjoy what he does and will do it better."
|As Donald Knuth noted in his Turing lecture "Programming can give us both intellectual and emotional satisfaction, because it is a real achievement to master complexity and to establish a system of consistent rules." As in other crafts there is an aesthetic satisfaction in accomplishing something with limited tools. And the value of simplicity, the value of sticking to kiss principle should never be forgotten despite all the temptations of the marketplace|
It is important to note, that other powerful and successful software development camps operate with different, more restricted, approaches. Some withhold source code, but provide the binary program free of charge and maintain it for years (that's how "freeware" camp in Windows OS operates). Some provide code with the expectation of payment in case the user likes the program, but allow free, unrestricted use anyway (that's how "true shareware" camp like famous PKZIP on which gzip was based operated). Some provide a warning screen that the shareware is not still registered (for example, Total Commander, RAR and other shareware programs)
The Software Idealist school (which has two schools that we will call Stallmanism and Raymondism, respectively) holds that mankind in general and programmers in particular has not yet achieved their full moral potential, and that they are (at least in principle) perfectible, if guided by wonderful new software development ideology. Foolish and immoral choices inherent in the creation of proprietary software explains all the evils of the existing software world and revolution was needed and actually already came in the form of either free software movement or its less pure form called open source software movement (here your mileage may vary depending on which camp you belong to :-). Both major Software Idealism schools rely on volunteer labor of programmers connected via Internet to produce immortal gems of software wisdom that will crush proprietary software developers like cockroaches.
In Stallmanism worldview proprietary software is immoral. Whether purely moral incentive actually work in a long run or not and what will happen when Linus Torvalds will become yet another retired dot-com multimillionaire with his own yacht is irrelevant to the achievement of true software justice, justice for all. Proprietary software is just reprehensible and sinful. No exceptions.
This utopian view holds that volunteer programmer potential is immense and can do everything including improving human nature that should get rid of those outdated economic rewards for software development and be satisfied working part time in McDonalds in order to be able to participate in the movement. So Stallmanism vision promotes pursuit of the high moral ground of software freedom which somehow guarantee the best software solutions. At the end of the day new liberated men should all storm this evil Bastille of software oppression which is of course Microsoft and dance on its ruins. Sometimes in their enthusiasm they can attack other sinful old fashioned proprietary software vendors. Until opening Solaris (and even after that) one of their favorite targets was Sun with its "Slowlaris" as they often mock it.
And if the unwashed masses who corrupt their soils by using Windows are slow in catching on, then it is the role of the intellectual vanguard (the keepers of programming craft, who in Eastern Europe might be called "programming intelligentsia") to lead them -- even if in the short run, the masses can be unhappy with the results because they might not be able to use full capabilities of their laptops, cameras or scanners. In general Stallmanists think that higher moral considerations should guide us and that those consideration somehow guarantee creation of a better software, the software which is as perfect as it is free.
The main point here is that the idea of sacrificing yourself to save humanity is very seductive to certain types of individuals. Probably instead of saving the world it is often wiser to learn to live in it. The latter is also more difficult.
|...the idea of sacrificing yourself to save humanity is very seductive to certain types of individuals. Probably instead of saving the world it is often wiser to learn to live in it. The latter is also more difficult.|
The term was introduced in my first paper demoted to "software realism vs. software idealism" problem and later expanded in Bad Linux Advocacy FAQ (Raymondism FAQ) (see Why the term Raymondism was introduced). While Stallmanism is preoccupied with software freedom and philosophically can be viewed as a brand of Anarcho Syndicalism, Raymondism preaches commercializing of open source development ("Linus revolution") as a new economically superior way of producing software. As such it is a neoliberal (see Neoliberal rationality) interpretation of software movement and as any neoliberal movement it is perfectly content with the existence of wealthy elite and greed. You can say anything about Stallman, but he is not a neoliberal. Eric S. Raymond is. Atomization of labor and replacement of salaries employees with powerless contractors without benefits working for corporate elite in "open source companies" is the hallmark of neoliberalism.
As money are intrinsically involved, this is a more sleazy movement with some wealthy elite and El Lunissmo himself involved in reprehensible behavior during dot-com era, but like in case of members of Politburo, or Catholic priests, they are "above suspicion" ;-).
Despite similarities, anarchism and neoliberalism are not compatible as ideologies, so there was a sharp split with Richard Stallman (see Open and Shut Interview with Eric Raymond):
While pragmatic Raymondism focuses primarily on marketing the concept of Open Source, idealistic Stallmanism insists that Free Software is an ethical issue; a matter of right versus wrong. By treating the issue as purely a question of efficiency, says Stallman, Raymondism "is not sufficient to give us freedom that is secure". In short, Stallman believes that since Raymondism lacks the conviction that Free Software is an end in itself, it threatens to subvert the aims of the Movement.
And as you can expect no love was lost between two branches of the movement. As Eric Hoffer aptly noted in his 'The True Believer':
"true believers of various hues ....view each other with mortal hatred and are ready to fly at each other's throat..."
Unlike Stallmanism which preached standard Anarchist tune that "property is theft", Raymondism stressed the economic superiority of open source development which is really neoliberal theme (TIMA -- there is no alternative). This claim of also makes is close to Vulgar Marxism (aka Economism). Economism is reduction of all social facts to economic dimensions. The term is often used to criticize neoliberal economics as an ideology, in which supply and demand are the only important factors in decisions, ignoring all other factors. As I noted in my response to Paolo M. Pumilia:
Date: Sun, 07 Nov 1999 11:42:36 -0500
From: Nikolai Bezroukov
Subject: Response to Paolo M. Pumilia
Dear Mr. Pumilia,
I appreciate your attention to my paper and pointing out its shortcomings I am painfully aware of. I just would like to stress that the paper was devoted to the exploration of the limitations of the open source development model. I never intended to write a point-by-point critique of the ESR's essays (although I do have a WEB page with webliography, and research materials). The main point was that ESR describes Open Source as a revolutionary phenomenon, whereas for me it is just another form of a scientific community. Similarly for me the Linux model is not a new and revolutionary development model, but just a logical continuation of the famous GNU project of the Free Software Foundation (FSF)-- the project with strong connections to MIT. I am convinced that this connection was crucial to the success of GNU project like the connection to the University of Helsinki immensely helped the Linux project in its early, most difficult stages.
I agree that the first several paragraphs contain polemic statements and as such are different from the rest of the paper. I apologize for any inconveniences that these statements have caused. I hope, however, that at least some readers enjoy it as a natural reaction to ESR's (IMHO harmful for the Open Source community as a whole) numerous and vicious personal attacks on Richard Stallman and the Free Software Foundation -- see his infamous letter to RMS -- Shut Up And Show Them The Code that is mentioned in the introduction to my paper. It is really outrageous and the lack of civility justifies the word "vulgar". In this response to the RMS Slashdot posting, ESR tried to present RMS as a dangerous fanatic and FSF as an organization that outlived its usefulness. The truth is that GPL-based products enjoy substantial commercial success and GPL proved to be a viable license for commercial software developers and distributors. The success of the Red Hat IPO is an implicit confirmation of this fact. The critical role of FSF tools (especially GCC) and GPL license for the success of Linux should not be underestimated.Some polemic that is present in my paper should not overshadow the main idea -- We do not understand anything until we know the limits of applicability. The OSS movement requires careful study of its limitations and without understanding these the participants can find themselves in trouble, which can be at least partially avoided. As a guiding principle, volunteer developers should better consider themselves to be a part of academic research and act accordingly to stay sane in the high-pressure and high-stress level world of Internet-based open source software development. Sometimes in its extremes this development environment can bear some alarming similarities to the atmosphere of a demanding cult. That's the main message that I tried to convey. I hope that for young developers the paper will help to avoid some traps and illusions inherent in the OSS model. I especially warned against Marxist religious overtones and Lysenkoism.
Any OSS participant should be aware of these religious overtones when "Open Source" implicitly means "sacred", which can negatively influence the investigation and adoption of other important technologies like BeOS, information appliances as well as the use of OSS software in the Windows environment. It's well known that Marxism with its utopian vision of communism as a future of mankind has been classified as religious atheism; Lunacharski (the first Minister of Education in Soviet Russia) and several other prominent Bolsheviks even wanted to convert Marxism into religion. Many Christian groups have combined their Christianity with Marxism (sometimes referred to as the "Christian Left.") Moreover the World Council of Churches has been described as "an instrument of Soviet policy" [see David A. Noebel's book Understanding the Times: The Religious Worldviews of Our Day and the Search for Truth. (1994)].
I feel that ESR is trying to get people to buy into Open Source software by romanticizing the entire process and stirring up a backlash against "M$". Unfortunately, ESR became a hostage of this OSS evangelism, which sometimes distorts reality in order to present OSS in a favorable light. The gap between discussion of the OSS development process in The Cathedral and the Bazaar, and a religious outlook may not be as great as it seems. If you view the Open Source Manifesto as a sacred text that must not be doubted or questioned, then it is just like the way Marxists treat Karl Marx's famous Communist Manifesto.
As for Lysenkoism I would like to stress that Lysenkoism is not only about political correctness. It also has a lot of common with so called high demand groups. A group does not have to be religious to be cultic in behavior. High demand groups can be commercial (corporations), political and technological. Be aware, especially if you are a bright, intelligent and idealistic person. The most likely person to be caught up is the one who says "It will never happen to me. I am too intelligent for that sort of thing." The idea of sacrificing yourself to save humanity is very seductive to certain types of individuals. Probably instead of saving the world it is often wiser to learn to live in it. The latter is also more difficult. That's why universities are the most fertile environments for high demand groups.
I would like to reiterate that ERS's views on the economic superiority of open source are close to vulgar Marxism with it's economic determinism. Contrary to your impression "vulgar Marxism " is a legitimate scientific term. As Professor Robert M. Young stated in his work "Marxism and the history of science" [see R.C. Olby, G.N. Cantor, J.R.R. Christie and M.J.S. Hodge (editors), Companion to the History of Modern Science. (1996), pp. 77-86.]:"The defining feature of Marxist approaches to the history of science is that the history of scientific ideas, of research priorities, of concepts of nature and of the parameters of discoveries are all rooted in historical forces which are, in the last instance, socio-economic. There are variations in how literally this is taken and various Marxist-inspired and Marxist-related positions define the interrelations among science and other historical forces more or less loosely. There is a continuum of positions. The most orthodox provides one-to-one correlations between the socio-economic base and the intellectual superstructure. This is referred to as economism or vulgar Marxism."
Another important aspect of the paper is the demonstration that the bazaar metaphor is internally contradictive. Linux actually can be classified as belonging to the cathedral model, not to the bazaar model according to ESR's own criteria. At the same time several authors pointed out that Microsoft can actually be classified as an almost perfect example of the bazaar model. I hope to return to this point later in my forthcoming response to ESR's letter published in this issue.
In conclusion I would like to reiterate that the paper was devoted to the problems that OSS has and I hope it will serve as a useful starting point for further research. Of course, both in argumentation and stylistically, my paper could be much better -- English is not my native language. I apologize for factual errors, grammar errors and misspellings. Please note that I corrected some of the errors in the final proof that was posted at the FM site a day or two later.
Raymondism views the method of development of software based on Internet connectivity and volunteer labor not only to be a new, better economic paradigm for producing software, but also the way of producing wealth for "open source elite" (in which he includes himself). The key statement and article of the faith of Raymondism is that this Internet connected "bazaar" software development method is inherently/inevitably superior (more productive) and as such should replace all other known form of development of the software (yes, it's that simple) and it does not matter if the result will be appropriated by commercial companies. That's why "ESR tried to present RMS as a dangerous fanatic and FSF as an organization that outlived its usefulness. The truth is that GPL-based products enjoy substantial commercial success and GPL proved to be a viable license for commercial software developers and distributors. The success of the Red Hat IPO is an implicit confirmation of this fact. The critical role of FSF tools (especially GCC) and GPL license for the success of Linux should not be underestimated."
The key claim about this "new economic paradigm" of development of software (based on labor of enthusiasts) is that it can be made into a source of enrichment of a few. Really neoliberal approach if you ask me, and from purely ideological standpoint, pretty close to Economism/Vulgar Marxism (see, again, my Response to Paolo Pumilia) :
I would like to reiterate that ERS's views on the economic superiority of open source are close to vulgar Marxism with it's economic determinism. Contrary to your impression "vulgar Marxism " is a legitimate scientific term. As Professor Robert M. Young stated in his work "Marxism and the history of science" [see R.C. Olby, G.N. Cantor, J.R.R. Christie and M.J.S. Hodge (editors), Companion to the History of Modern Science. (1996), pp. 77-86.]:
"The defining feature of Marxist approaches to the history of science is that the history of scientific ideas, of research priorities, of concepts of nature and of the parameters of discoveries are all rooted in historical forces which are, in the last instance, socio-economic. There are variations in how literally this is taken and various Marxist-inspired and Marxist-related positions define the interrelations among science and other historical forces more or less loosely. There is a continuum of positions.
The most orthodox provides one-to-one correlations between the socio-economic base and the intellectual superstructure. This is referred to as economism or vulgar Marxism."
This suggested by me analogy with Vulgar Marxism provoked very sharp response by Raymond to my first article in First Monday (as Richard Poynder wrote 'ZDNet columnist John Carroll once characterized engaging with Raymond as akin to taking part in a café debate where Raymond is "the guy at the table trying to take out his opponent's eye with a fork" ' :-). Here is one polite criticism of my work from the esteemed open source guru (Samizdat Stinks on Ice):
Relying on Bezroukov's account was a bad mistake. The man is a crank and an idiot.
When deviating opinions cannot be tolerated and persons who hold them called traitors, or cranks, or idiots, that suggests that the particular person performs the role of "Mindguard", self-appointed member of the group, who defends the group-approved dogma and shield the group from dissenting opinions [Wikipedia]. Or, if we dig a little bit deeper, demonstrates the typical behavior of cult leaders and psychopaths (those two types of personalities intersect: simplifying, cult leader is a psychopath with strong personal charisma and ready-made doctrine ;-). For example, American family foundation lists 14 Characteristics of such organizations ( Cult Characteristics )
- The group is focused on a living leader to whom members seem to display excessively zealous, unquestioning commitment.
- The group is preoccupied with bringing in new members.
- The group is preoccupied with making money.
- Questioning, doubt, and dissent are discouraged or even punished.
- Mind-numbing techniques (such as meditation, chanting, speaking in tongues, denunciation sessions, debilitating work routines) are used to suppress doubts about the group and its leader(s).
- The leadership dictates sometimes in great detail how members should think, act, and feel (for example: members must get permission from leaders to date, change jobs, get married; leaders may prescribe what types of clothes to wear, where to live, how to discipline children, and so forth).
- The group is elitist, claiming a special, exalted status for itself, its leader(s), and members (for example: the leader is considered the Messiah or an avatar; the group and/or the leader has a special mission to save humanity).
- The group has a polarized us-versus-them mentality, which causes conflict with the wider society.
- The group's leader is not accountable to any authorities (as are, for example, military commanders and ministers, priests, monks, and rabbis of mainstream denominations).
- The group teaches or implies that its supposedly exalted ends justify means that members would have considered unethical before joining the group (for example: collecting money for bogus charities).
- The leadership induces guilt feelings in members in order to control them.
- Members' subservience to the group causes them to cut ties with family and friends, and to give up personal goals and activities that were of interest before joining the group.
- Members are expected to devote inordinate amounts of time to the group.
- Members are encouraged or required to live and/or socialize only with other group members.
It is interesting to note that from this list characteristics (1), (2), (3), (4), (7), (8), and to lesser extent (10), (13), and (14) are applicable to Raymondism :-). That might be accidental, but most probably it is not.
There are multiple additional problems with Raymondism as neoliberal interpretation of open source software movement, which I covered elsewhere (see Bad Linux Advocacy FAQ (Raymondism FAQ) ), but one important problem is that as soon as we allow large sums of money into the equation, large open source projects gradually evolve into a form of cooperative development by and for large firms with more or less closed circle of developers elite (or using less politically correct term, open source oligarchy). Firms which bankroll the salaries of those elite developers (as well as propagandists like Eric Raymond), implicitly dictate the direction of development (this is sometimes called hijacking of open source project). In any case, the primary goal implicitly became catching and maintaining market share for "sponsors" (not unlike proprietary evil twins do), not so much about the advancement of the state of the art in academic sense, or free exchange of knowledge.
|The primary goal in large open source project implicitly became catching and maintaining market share for "sponsors" (not unlike proprietary evil twins do), not so much about the advancement of the state of the art in academic sense, or free exchange of knowledge.|
In a way, Raymondism as many "spiritual movements" hides a corpse in their closet -- the orgy of greed of leaders during Linux gold rush which was a part of dot-com boom. Of course, frantic denials and counter accusations by those in charge presently follows almost automatically. And they are usually accepted without questioning by devotees, who cannot get over the shock of such revelations. As somebody said they are unable to handle the truth. This sentiment was well expressed in one comment on my paper:
...Your article is powerful. Of course it will help many developers to build up more objective view on the issue. It is a perfect critics and everything is 90% true. BUT it looks at the Open Source only the negative way.
I think if this article will be seen by a developer with weak independence, one will never participate in OSS projects.
The author of this letter began to participate himself in one of such projects not long ago and this article was like a bomb, exploded in the core of his heart. He will continue to go, but he was shaken in his confidence. This may be compared with telling to a small child that Santa Claus doesn't exist.
Breaking the Internet Dream and annihilating the idea of Open System and Open Software IS AN INTELLECTUAL SIN.
Finances are always a tricky issue for neoliberal interpretations of open source movement like Raymondism which accept "greed is good" postulate. Human groups always wish to grow. Accountability is often not considered appropriate. Danger arises that members of the inner circle became too greedy.
History of commercializing of open source ("Linus revolution") has shown pretty convincingly that it is an internally contradictive undertaking with strong corrupting influences for leaders of the movement and shaky, "between two chairs" position for the firms who support the movement (IBM, Red Hat, in the past Novell, etc). The recent twist in Red Hat long history of trying to balance openness with commercial success. And in this respect Red Hat is better then many other open source software vendors. At least they managed to produce a leading Linux distribution for more then a decade, unlike "make money fast by IPO" rip-offs, such as VA Linux were Eric Raymond used to be a PR man, or "make splash, chip, IPO and vanish" startups like Transmeta where Linus Torvalds served in a very similar role.
Still now they want to withhold kernel patches from clone makers such as CentOS and Oracle. It is logical that a commercial enterprise wants to conceal information that represents competitive advantage and make the competitors life more difficult. But this puts it against the spirit of open source movement. And this is just the most recent example of a long trend. Commercial providers of open source prefer open source in as impenetrable for competitors packaging as they can get away with :-)
Commercial providers of open source prefer open source in as impenetrable for competitors packaging as they can get away with :-)
Raymondism promotes the view on "open source" as a marvelous market based ("bazaar") utopia, kind of "bright future of mankind" like neoliberalism in general (although ESR of course denies the connection). Like all the great utopias, it is free of personality conflicts and everyone freely works for the Common Good, implemented via Red Hat, IBM, Novell and some other players that actually not unlike evil twins of proprietary software world exchange your money for delivered goods. Of course the key difference is that they do it for the benefit of all (but first of all their top management and selected members of Linux elite) under the benevolent dictatorship of El Linusimo. Somebody said that money do not smell.
Paradoxically in "free vs. open source discussion" I am on the RMS side (Stallmanism side, if you wish ;-) and I think that RMS is right by saying that he's not sure to what extent the Free Software is compatible with corporate desire for profit.
It's much more straightforward and truthful to say it that way, rather than jump over the head trying to sell open source projects to the highest bidder as Eric Raymond and Linus Torvalds did during dot-com boom. There is one terminological problem: some people (RMS is one example) distinguish free software ("free software"="GPL-based software" in RMS interpretation ;-) from Open Source (umbrella term that includes BSD license, Artistic license and LGPL), some do not. Open source is snappier, clearer, less ambiguous, and close enough to the same thing. As such it's preferable to the 99% of people. I know that RMS disagree, but so be it. And actually if you are semantic fundamentalist you can see the GPL has problems with coercively redefining the word "free" (that's why so much material on GNU site is devoted to it ;-). BSD license is more free that GPL in both "free like in beer" and "free like in freedom" meanings of this word.
But terminology notwithstanding, RMS views are limited too because under the huge umbrella of "software development" there are several processes and distinct activities:
The principal advantage of open source means that for simple programs the possibility of adapting program for your needs largely compensates for the shortcomings of this program. This is one of very important meaning of KISS principle. Of course you need to be a programmer to use this advantage, but still the code of carefully written, well structured program and documented program is not unlike an article in academic journal. The results are reproducible: it provides a good starting point for others to explore the same area but standing of the shoulders of previous contributor. If we lose adaptability of code (which panned automatically when the size of codebase exceeds a certain threshold), then availability of source code is still valuable as insurance, but not much more then that.
In other words, only reasonably short, well structured and well documented programs are useful for adaptation. But the key precondition here is that they should be able to transfer some useful for recipient knowledge, the set of key ideas, the property which dissipates as program grows larger and larger. In other words, real open source is as much about knowledge-transfer as it is about creating of free alternative to commercial software. If not more. Of course everything is relative and there are such strong and dedicated programmers, who can break the fog of Linux kernel and start participating in the development even with version, say, 2.6.3x. But those individuals are extremely rare and one robin does not make the spring: they do not signify that the transfer of knowledge is possible to mere mortals.
It might be more properly to call huge complex codebases, such as Linux kernel 2.6.3x or Apache 2.x not open, but semi-open program. Because for most members of community they are undistinguishable from closed. In other words the source code is just a part of process of transferring and dissimilating knowledge.
It might be more properly to call huge complex codebases, such as Linux kernel 2.6.3x or Apache 2.x not open, but semi-open program
And if you do not wish to transfer knowledge you can "fake" open source: you still can provide open source code, but you remove all the ladders that help to see its internal architecture, the choices made and compromises adopted. As RMS aptly said:
... I would choose a bare-bones unreliable free program rather than ... reliable proprietary program...
But this is also true about large non-documented or poorly documented open source program. Any specialist in in renovation of commercial software can testify that the task of adapting large complex codebase to new purpose is not unlike moving existing commercial programs from one platform to another or rewriting software written in some old, no longer widely used, or platform limited programming language in some more current programming language (for example, Java or Python). And, that far from an easy task. Believe me, companies pay very good money for specialists skilled in such an activity, who are able to port large, complex ancient programs, say, in PL/1 or Cobol to, say, Java (which is nothing but new Cobol with more fancy name (and I was involved is such activities in the past enough to understand that in many respects PL/1 is still superior to Java :-).
Again the key property of open source is that "bare-bone" open source program does have additional value that might compensate for its many other real or perceived faults. The windows of opportunity for knowledge transfer is not automatic and to a large extent disappear with the growth of the size of the codebase of the program. So KISS principle is of paramount importance for open source. In other word complexity of codebase is the cancer of open source.
I would like to stress again, that the principal advantage of open source: possibility of adaptation to a different purpose or domain, exists only up to certain amount level of complexity, which in a very fuzzy way can be approximated by number of lines in a program. That's why scripting languages are so important and Perl, TCL, PHP and Python, not Linux should be considered the flagships of open source. From this point of view Linux is a just a conservative reimplementation of Unix that introduced almost nothing new into operating system kernel design. And BTW Unix introduced at least seven: C language as system programming language, hierarchical filesystem, pipes and a set of pipes friendly utilities/filters, regular expressions, devices as files, shell as the mother of all modern scripting languages, and first built-in TCP/IP stack). If one compares Linux with BE OS, Inferno, or even with OS/2 and Amiga one can see that in major design decisions Linux is an extremely conservative OS. As Rob Pike noted in his "Systems Software Research is Irrelevant" (http://plan9.bell-labs.com/cm/cs/who/rob/utah2000.pdf) Linux can be considered as a sign that computer science research became irrelevant and he claimed that the whole situation in OS design is generally bad and requires action.
As Rob Pike noted, Linux can be considered as a sign that computer science research became irrelevant and he claimed that the whole situation in OS design is generally bad and requires action.
The key point is that you can convert any open source project into an close analogy of a proprietary software development project (or "fake it" using less academic terminology) by just by overcomplicating the code base and removing/withholding the information about architecture. Large software development project is much more the codebase. It includes the tremendous amount of knowledge about the architecture (which often is held by just key developers; that's why replacement of key developers is so disruptive on late stages of the project), build infrastructure, etc. With huge codebase (especially written in C) open source projects gradually start to approximate binary code as the number of people able or willing to look inside the code base approaches zero. At the same time open source development provides competitors with all the necessary information for replication of the project enforcing something like a law of jungles in software development when the largest gorilla rules. A nice example in this regard was Oracle launch of their own distribution cloned from Red Hat.
|You can convert any open source project into a close analogy of a proprietary software development project just by overcomplicating and obscuring the code base and removing/withholding the information about architecture.|
The second tendency is connected with the stratification of developer in any large, successful open source project. As key developers became much closer to "big money" they tend to form elite (which politically incorrectly is called oligarchy) which is difficult or impossible to dismiss. That also gives an impulse to building of cult of personality of a leading developer(s).
I tend to think that this 'Sudden Wealth Syndrome' is applicable not only to children of rich. Behavior of key figures of open source during dot-com book with tits cosmic valuations of unprofitable companies and consolidation frenzy is a nice illustration of the problems that arise when quest for knowledge is mixed with quest for money. The rot among key figures of open source movement, who became a despicable hypocrites in the process was undeniable. Dot-com boom turned them into well-paid promoters of questionable financial products, a real patsies of Wall Street. And that includes Transmeta with Linus Torvalds as a front man for the IPO (see Selling Transmeta (TMTA) ) and VA Linux with Raymond as heavy PR artillery. For example, Raymond was granted 150,000 share options of VA LINUX SYSTEMS INC at a strike price of less than four cents apiece, according to SEC filings, for a total value at IPO prices of about $32 million.
Of course later those companies suffered from "financial irregularities", shady accounting practices to justify astronomic valuations, etc. But money were already made. Some results of those activities resulted not only in rip-off of institutional investors who shown have known better, but a direct rip-off of open source enthusiasts, who decided to support those ventures with their hard earned money. Here is the message that I had found on the Linux Today forum about "absurdly rich" Eric Raymond:
It's really sad, but greed is greed even if it's connected with open source. And while promoting companies before IPO they never commented on subsequent press releases like "The company denied that it expects to find evidence of financial irregularities either in its revenue recognition or expenses" (VA Linux). Accompanied by resignation of CFO, CEO or both. There was almost no criminal prosecutions, neither among Wall Street analysts that promoted those firms, CEOs of those "make money fast" firms, or PR frontends. Everything was swiped under the carpet and authorities pretended that this was not a fraud but just a little bit overstepping of regulations trying to turn a profit :-). Kind of dressed rehearsal for subprime loans boom/bust.
The Me use Linux too IPO open sore Linus open ebiz ASP solutions satire aptly described crazy atmosphere of this gold rush bubble that partially was inspired by Raymondism (See Linus Midas Touch for more information):
The final destruction of what used to be a charming little OS scene arrived today, Monday, December 13, 1999.
Linuxtoday is spewing forth "me-use-linux-too-IPO-open-sore-Linus-open-ebiz-ASP-solutions" press releases from every backwater, buzzless Joe Q. Corp with a hotmail account...
OS figureheads are being courted for interviews with a veracity that is usually reserved only for pathological child molesters and internet CEOs...
Forty thousand "Embedded Internet eSolution Firewall Privacy Biz Remote" solutions are being deeply discounted to the five people who care enough to add one more yeahd00ditssecure.pl script to their boxes...
2-bit players are buying half-bit companies without a dime to their names just to get at the word Linux in their press releases...
Contrast this feeding frenzy with typical behavior expected from academic players. When you become a scientist, you essentially give up the quest for great wealth. Yes, you get a decent (or half-decent) wage. But real scientist usually avoid to capitalize on their discoveries. They just give them away, the way BSD developer do. That's how Donald Knuth behaved with his contributions to open source. Of course there are entrepreneurs in academic closing, but they are more of an exception then the rule and they are usually not respected by colleagues. You are expected to publish honest work reveling what you discovered and that's it. World can take it or ignore it. And you don't get a penny from publishing an important. groundbreaking article in a leading magazine; often you pay to help to offset the typesetting costs.
All in all, I tried to communicate a more objective message that can mobilize developers by giving them a clear sense of what OSS is about, what are major pitfalls and difficulties and how to avoid them or at least lessen their influence on the project. Choices are difficult and for talented programmer jumping into open source in order to prove themselves is just one possibility. Not always the best.
Also level of contribution to open source can and should vary. Some level of contribution is advocated by the authored as pretty effective medicine against dull, bureaucratized and stiffing for innovation atmosphere of IT departments in many large corporations with clueless bosses and complete technological dysfunction (which is not that different from one other dysfunction :-).
Here, not in fairy tales about bazaar models or illusive and coercive freedom via GPL, the author see future of open source and free software development. I see the main value of open source as a kind of scientific commons, that should be protected as an important part of knowledge ecosystem.
Again here the example of Free/Open/NetBSD is an really inspirational as those projects survives and had shown impressive results ( FreeBSD jails, OpenBSD OpenSSH project) without injection of doping from heavyweights like IBM into the community :-).
GPL based programming commons are now become increasingly privatized. And with the privatization comes real dangers such as overcomplexity, sucking to big donors like IBM, etc. That's bad for preservation of classic Unix, that halted important avenues of research and could be bad news for both the future progress of programming as an art and for technological progress. The erosion of the programming commons is not easy to stop. Here I want to call the alarm.
A key element of the open source is that outside of commercial ventures the work of programmers is and should be motivated by the search for understanding, not profit. Indeed, excessive influence of large companies on open source projects could kill the goose that lays the golden egg. In the terms used by Polanyi (1967), society should appreciate and protect “The Republic of Open Source”, not so much "Open Source Incorporated".
The most promising part of open source is connected with scripting languages (LAMP is one example; usage of Perl in bioinformatics is another), where it really opened new horizons and beat commercial developers such as IBM and Microsoft. Yes, in this area open source developers did beat Microsoft.
All in all open source development helps to keep developers of proprietary systems honest and I think that in such important products as Office 2003, Windows 2007 and Windows 7 mobile there is an implicit contribution of open source. At least it did help to revitalize and focus Microsoft development.
At the same time, as practice have shown, there is a distinct danger in open source development of screwing existing software by new developers who came late to the project (or after the initial developer of commercial company abandoned their creation) and spoil it. Also "open source companies" could’ve hired subject experts to consult, and give them a living wage to do so for some period, instead of building platforms to dehumanize and devalue programming labor.
It's time to discount fairy tales about open source and return to more realistic view on open source. My impression is that the proper way of open source development is exemplified by Free/Open/NetBSD development, especially before the removal of attribution clause from BSD license. Which reflects an academic understanding of a proper use of research results -- attribution. I also value BSD movement as a movement that creates and support an alternative software ecosystem, ecosystem that values KISS and provides open honest exchange of knowledge between participants. My impression is that knowledge exchange in system programming part of the Linux community is in danger, and that the costs of eroding this open exchange of knowledge due such factors as excessive complexity (necessary for competing with proprietary software) and GPL based commercialization (in which the complexity serves as a barrier of entry much like in commercial software development) are likely to be high. Latest adventures in Linuxland with the introduction of systemd daemon (which was pushed down the throats of developers by Red Hat) do not inspire too much confidence. In general, the quality of initial three releases of Red hat 7.x distribution (7.0-7.2) -- tremendously complex and tremendously capricious -- is suspect. The question to be asked is what will change if tomorrow Red Hat start distributing its OS as a closed source? It is by-and-large already used as a closed source OS by 99.95% of its users. Red Hat architects definitely do not value simplicity anymore and pursue other goals, trying to preserve and enlarge their market share. Their licensing model reflects just that too. This is not too bad per se, but this interplay between complexity and openness needs to be understood.
I wrote five papers and one eBook analyzing this problem from various angles:
Labyrinth of Software Freedom (BSD vs. GPL and social aspects of free licensing debate)
Open Source Software (slides by Gerard C. Weatherby)
The Mythical Man-Month by Frederick P. Brooks, Jr. (1975)
No Silver Bullet - Essence and Accident in Software Engineering by Frederick P. Brooks, Jr. (1986)
Rapid Development by Steve McConnell
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: July, 22, 2017