Open Source and Russell's Paradox - A New Commons?

Jesus Villasante, a senior official at the European Union Commission in charge of Software Technologies in a spontaneous panel discussion on open source decided to shine a light on the lack of coordination, the influence of commercial interests, and the inability to evolve beyond current corporate paradigms. "Companies are using the potential of communities as subcontractors--the open-source community today (is a) subcontractor of American multinationals." Mr. Villasante is completely correct in his analysis, although I doubt he will find many who will agree in either the corporate camp or in the open source camps.

Well, I do have extensive experience in this area. I co-pioneered the first Berkeley open source operating system 386BSD using our own personal resources and with the support of the editor and staff of one of the most popular American technical magazines at the time - Dr. Dobbs Journal. Along with doing a complete novel port to the X86 architecture and new architectural design, we documented the porting process, kernel and architecture. We did not believe that simply reading the source was sufficient to understanding, and it required extensive documentation and open design review to provide releases that were reliable enough for researchers (much less consumers). This was the Berkeley way, and we cleaved to it with the support of the technical press.

Even with many releases, there was extensive documentation and careful attention to design trade-offs and discussion - for example, "Is it better to commit time to a patch if the Berkeley architectural goals from 1982 from Dennis Ritchie et.al. intended a new subsystem?" and "Are artifacts such as brk() wise in perpetuating so that some legacy programs can be run while impeding evolution in modularity?". We addressed these and many other issues.

However, what we found is that various interests in the open source and business communities did not wish any new paradigms or evolution of the operating system if it required any changes to legacy applications (some suspiciously acquired). And this was the beginnings of a lot a bad blood in the Unix community.

Working as we were openly - from the very beginning of this project - with the press and the technical community, we were loathe to handle kernel work in an expedient manner that did not clearly demonstrate independent ownership, evolution, and novel work. We did not object to others doing this - the source was available - but that was not the 386BSD design goals in evolving Berkeley Unix.

Suffice to say, this project and it's coverage provoked much jealosy and envy, especially when source was rejected as being "non-novel" or antithetical to the Berkeley architectural vision established in the 1970's - new work, design innovation, and documenting and testing (through papers, articles, or other means) these ideas.

We released our final version of 386BSD on CDROM (see the "386bsd Release 1.0 Reference CD-ROM") through Dr. Dobbs Journal after two years of feature articles discussing the architecture, completed the first volume of the kernel design book Operating System Source Code Secrets Volume 1: The Basic Kernel intended for university study, in 1996.

By this point in time, we were observing many different groups intentionally regressing the operating system to include very old code. They did not understand why some of these artifacts appeared in this old code base, nor were they interested in learning how and why such was developed, so they could not redesign to remove elements which reflected architectural designs stemming from the minicomputer days, for example, that actually impeded creating a stable secure operating system. Their only interest was to collect as much code as they could. It became a race for who could be bigger.

Minimalism in design is the key to evolving a secure and robust operating system. However, as long as the open source community believes that the challenge is to dominate with lines of code, which in turn allows the dominant corporate interests (e.g. IBM) to exploit due to the sheer complexity and obsfucation of mechanism and function, we will also most assuredly suffer from a devolving environment where innovation becomes too difficult to attempt.

If this continues unabated and unexamined, according to a few of the insiders on Sand Hill Road the investment risk versus benefits for many open source projects will be too great to fund any innovation at all.

According to William Jolitz, open source is now undergoing a form of Russell's Paradox. "If any coherent condition may be used to determine a set, then the self-reference of open source implies collecting all elements of itself regardless of propriety and correctness. This explains the need to collect all source elements - good, bad, indifferent, proprietary - under the rubric of 'open source' before any modification of the set is allowed. It is continually self-referent and indeterminant. The state set, in sum, is not properly formalized".

"The only solution to this dilemma is formalization. The very act of incorporating in open source without regard to specification is what is breeding this problem further. In mathematics, we view it as a form of the 'vicious circle principle'."

386BSD began with a specification (see "Creating a Software Specification"). It continued with an "in the moment" monthly series documenting the changes, reasoning, and design analysis. No one else has done this as methodically in open source operating systems (although several groups have followed much of this model in applications), but this is exactly the process through which the design was successfully evolved to a fully modular, secure operating system in a period of four years with a very small staff.

It can work again, but only if a complete understanding the the failings as well as the successes of open source is valued and respected. Elsewise, we are destined to expend a great deal of time, money, and livelihoods replicating the same problem.

According to Ingrid Marson of Cnet, Mr. Villasante went on to discuss the need for open source independence. "Open-source communities need to take themselves seriously and realize they have made a contribution to themselves and society. From the moment they realize they are part of the evolution of society and try to influence it, we will be moving in the right direction." I certainly couldn't agree more.