Monthly Archives: December 2007

On the shortest Python program

[First published in GOTOXO as Python-XO: On the shortest Python program on December 19, 2007.]

As reported in Caduceus Redux, Robert Bolgar says, “Maybe I should gear up my brain to learn some Python, too. About time I woke up to the computing world.”

I write this note to Josh and Zander Bolgar to provide a suggestion on how to help Dad wake up to the world of computing. Other members of the XO Generation may find it a way to help start their parent’s education on programming as well.

One of the most common sources of error in writing in a program is the failure to properly deal with what are known as “edge cases.” For example, running a loop once too often, or failing to run it far enough.

A further example is whether the program properly deals with the “null,” or empty case.

Since Python is based on set theory, let’s see if the Python compiler handles the case of null input properly. Linux provides many useful features, among them a perpetual source of nothingness in the form of a special device known as “/dev/null”. It appears as a file, but whenever you try to read it you get only the end-of-file signal. There is no data in that file save its end.

The question then is what happens when you execute:

$ python shortest and longest sentences in natural language, in which a letter consisting of a single character (“!”) communicated a meaningful message. But Python is even better in that you can write a correct program by writing a program with no characters at all!

Zander and Josh can thus start their dad on his programming career by just having him execute the empty Python program.

If is of course much more fun to write programs that are longer and do some useful work, as I will try to show in future posts in this series. But education in any subject, including programming, must begin with a first step, even if it is just to show that “nothing ventured can still some education gain.”

A Green Box For Learning

[First published as A Green Box For Learning on December 19, 2007.]

When I speak about the XO these days, and I do so often, I frequently begin a sentence with the phrase, “This little green box.”

Though my own XO hasn’t yet arrived, I realize that I had my own Green Box For Learning over fifty years ago, as I have described in On Libraries: The Ernie Pyle Memorial Home/Library. Here are some pictures of it from a postcard I found via eBay:

200712 038
The Ernie Pyle Library in Albuquerque, New Mexico

200712 037
Front of postcard

200712 039
Back of postcard

One of the reasons I write this blog is to hopefully provide some education, and perhaps even some inspiration, so that some of the members of the XO Generation will make it their career to be librarians in their own country, providing Boxes for Learning both using the XO Laptop and in the form of buildings where all are welcome to come find a book and read it.

On Von Neumann’s First Program

[First published as XO-Python: On Von Neumann’s First Program on December 17, 2007.]

While doing some web research preparing the previous post in this series on Python and the XO, Python-XO: Programming as applied mathematics, I came across a fascinating article by Don Knuth about John von Neumann’s first program, Von Neumann’s First Program (PDF).

John von Neumann was one of the greatest physicists and mathematicians of the 20th century. He was legendary for his ability to do complex mathematical computations in his head, and set out much of the foundations of the structure of computers as we use them today. Back in my days in grad school several decades ago it was common to hear his name associated with computers, though as Wikipedia notes this is now rarely the case.

Though I had read some of von Neumanns’ early work in the late 1940’s in typescript form in the Courant library while in grad school, I was not familiar with this work, which was done in 1945 It was kept by Herman Goldstine, another of the pioneers of computing, in manuscript form. Don Knuth, the best computer scientist of his generation, begins his paper as follows:

A handwritten document now in the possession of Dr. Herman H. Goldstine contains what is probably the earliest extant program for a stored program digital computer. Its author, the remarkably talented mathematician John von Neumann (1903-1957), was in the process of refining the stored program concept as he was writing this code; so his program represents a significant step in the evolution of computer organization as well as of programming techniques. In this paper we will therefore investigate the contents of yon Neumann’s manuscript in some detail, attempting to relate its ideas to other developments in the early history of high speed computing.

The program we will study is not what we might expect an “ordinary” mathematician to have written; it does not solve a partial differential equation! Instead, it deals with what was considered at that time to be the principal example of a nonnumeric application for computers, namely, the problem of sorting data into nondecreasing order.

Shortly thereafter we learn that:

The key question was whether or not the proposed instruction set provided a satisfactory means of logical control for complex processes, and so he felt that a sorting program would be a most instructive test case. Furthermore, the existence of IBM’s special purpose machines for sorting gave him a standard against which he could measure the proposed computer’s speed.

By way of background, the “IBM machines” mentioned were not computers, but specially-built mechanical devices that could sort punched cards. I go back far enough that I can recall using such machines, and they were a joy to use, though the occasional jam could ruin a day. They gave a real-time demonstration of what is known as a “radix sort.”

It is worth noting that von Neumann was not only working out fundamental principles of operation of computers as we know them today but was also from the start interested in measuring the performance of his program. He was not programming in the abstract world of Turing machines (about which we will learn more in forthcoming posts) but in the real world, a world where cost and performance mattered, especially given the great cost needed to build computers in those days, even though von Neumann was designing for a machine with only three 32- bit registers and 8192 words of memory. The current state of the art at the time, as expressed by Knuth, was “The ENIAC was a highly parallel computer; weighing over 30 tons, it involved over 19,000 vacuum tubes, 1500 relays, etc. Because of its electronic circuitry, it was considerably faster than any computing machine previously built. But it had only 20 words of internal memory, and it required complicated manual operations for setting up a program on plugboards.”

Hardware afficionados can appreciate the following comment:

The EDVAC memory was to be divided into 256 “tanks” of 32 words each, operating in a cyclic fashion. Word 0 of each tank would pass a reading station one bit at a time, then (32 bit-times later) word 1 would be available,…, finally word 31, then word 0 again, etc. Thus the accessing of information from tanks is essentially the same as we now have from drums or head-per-track disks.

This means of accessing information is not only that used in disks today but was also used to access memory in the earliest versions of what is now the x86 architecture. Indeed, the requirement to account for a similar delay in accessing memory led to the infamous “wrong” byte order in the 8080 architecture that has plagued generations of programmers. [1]

Key to von Neumann’s means of expressing programs is the notion of sequencing, what is called “control flow”:

Instructions were to be executed from consecutive locations, unless the sequence of control was modified by a JMP order. If the control sequence would come across a number (not an instruction word), the effect would be as if an LOD instruction were performed referring to this number.

Von Neumann sketched out only part of the complete algorithm, in a form of notation similar to mathematics. Knuth translates that into “pseudo” code that is is recognizable as code to any programmer. “Pseudo code” is code not for a particular machine, but code for a hypothetical machine to illustrate how a computation can be carried out.
A few sections are of particular interest to those first learning a programming language such as Python:

After having written the program, he assigned actual addresses to the subscripted ones. In order to make the code relocatable, for use as a general open subroutine, he assigned the addresses relative to an unspecified starting location e. His address assignments are shown in Figure 2 at the right of the instructions.

Von Neumann discussed the relocatability of this routine by enumerating the nine instructions which are variable (those whose codes depend on p, EXIT, or the relocation factor e). He didn’t say exactly how these instructions were to be changed after they have been read in from tape; he apparently did not yet realize that the limited EDVAC code he had proposed (with no shift instructions, for example) made it difficult to insert p into the “PIK” and “PUT” instructions, since the machine could only store into the address field of instruction words. It is perhaps significant that he thought of this program as an open subroutine, not closed, since he did not regard EXIT as a parameter on a par with n, m, location(x0), etc.

Von Neumann here first sketched out, or defined, what are now known as subroutines or procedures. These are expressed in Python using the def statement.

Not a great deal of technical expertise is needed to read Knuth’s full paper. Much of it is quite accessible; it provides a fascinating insight to the first expression of key concepts that every programmer takes for granted. As such, it serves as a reminder that what seems commonplace now was once unknown.

Notes:

1. I once heard a talk by the designer (whose name I can’t recall now) of the Intel 8086 architecture. He said that during the design process he had been given the option of putting the bytes in the “right” order, but decided to leave things as they were. This comment was met by a loud groan from all the programmers in the audience, and he said he had come to realize the error of his ways.

Programmers sometimes have to live with their mistakes for decades. For example, if you ever happen to meet a Google employee named Stu Feldman, give him a hard stare while silently saying the phrase “tab character” to yourself. You don’t have to say anything out loud, just don the appropriate look of despair as you recall the hours that have been wasted putting tabs at the right place in “make” files. He’ll get the message. You will make his day.

Programming as applied mathematics

[First published as Python-XO: Programming as applied mathematics on December 17, 2007.]

Python is the programming language used to write most of the applications that come with the XO Laptop.

In Python-XO: The Farmer in the Dell, I said that programming is just a form of writing, and gave a brief example of a program in the Python programming language.

The writing that is programming is scientific in nature. Programs specify how computers are to operate. Computers– including desktops, laptops, or contained within wrist watches, printers, cell phones, and games such as the Sony Playstation and the Microsoft XBox — are the creation of scientists and engineers. The essential elements of programming languages are dictated by the structure of computers and are mathematical in nature. Programming is thus a form of applied mathematics.

However, this view of programming as applied mathematics is not a common one. For example, let’s look at several views of Python.

Guido Rossum, the creator of Python, says, in his Executive Summary:

What is Python? Executive Summary

Python is an interpreted, object-oriented, high-level programming language with dynamic semantics. Its high-level built in data structures, combined with dynamic typing and dynamic binding, make it very attractive for Rapid Application Development, as well as for use as a scripting or glue language to connect existing components together. Python’s simple, easy to learn syntax emphasizes readability and therefore reduces the cost of program maintenance. Python supports modules and packages, which encourages program modularity and code reuse. The Python interpreter and the extensive standard library are available in source or binary form without charge for all major platforms, and can be freely distributed.

Often, programmers fall in love with Python because of the increased productivity it provides. Since there is no compilation step, the edit-test-debug cycle is incredibly fast. Debugging Python programs is easy: a bug or bad input will never cause a segmentation fault. Instead, when the interpreter discovers an error, it raises an exception. When the program doesn’t catch the exception, the interpreter prints a stack trace. A source level debugger allows inspection of local and global variables, evaluation of arbitrary expressions, setting breakpoints, stepping through the code a line at a time, and so on. The debugger is written in Python itself, testifying to Python’s introspective power. On the other hand, often the quickest way to debug a program is to add a few print statements to the source: the fast edit-test-debug cycle makes this simple approach very effective.

Eric S. Raymond, another well-known programmer, says in his essay, Why Python?:

I had already heard just enough about Python to know that it is what is nowadays called a “scripting language”, an interpretive language with its own built-in memory management and good facilities for calling and cooperating with other programs. So I dived into Programming Python with one question uppermost in my mind: what has this got that Perl does not?

Here is part of the brief summary from the Python wiki:

What Is Python?

Python is a programming/scripting language that can be used on many different computers and operating systems, including Windows, Unix, Macintosh, etc. I’ve heard of it being run on everything from palm computers to Cray super computers. For a number of reasons, it’s the *best* way to learn computer programming in general. The first few that come to mind are:

* The interactive “shell” allows you to instantly see if you did it right. Personally I find the Python shell easier to use than a calculator for everyday math at home and at work.

* The language is elegant and just plain makes sense, which means you or someone else can read your code weeks or months after you wrote it, and it will still make sense!

* Python was designed from the ground up for learning programming.

* You gotta love the awesome Python community of people who really want to help, such as the Python tutor email list.

* It has a short learning curve, which can have you programming successfully within minutes (really).

* Including the one that comes with the free Python download, there plenty of tutorials available for both programmers and people new to programming.

* It’s free and open source.

* It was named after Monty Python, which makes you wonder…..

* It’s a good stepping-stone to languages like Perl, Java, and C++, which make more sense after picking up some Python.

* It’s cross-platform, so the code you write for your Windows PC at home can be run on the linux server at work!

Though all these summaries are accurate, and I agree with most of the points they make, they don’t capture the essence of Python as I see it.

I spent the best years of my professional life — over a decade’s worth as it turned out — working on SETL, a language inspired by a simple observation by Jacob T. “Jack” Schwartz:

It would be an interesting experiment to base a programming language on finite set theory.

Python is based in part on some of the ideas found in SETL, and is the language closest in spirit to SETL that is currently in widespread use. The power of Python comes in large part from the power of set theory itself, for set theory is fundamental to mathematics. Here is an example, in the form of some pictures.

200712 032
On Sets

The page on the left is from Naive Set Theory by Paul R. Halmos. The part just above the miniature terminal says (emphasis added):

A pack of wolves, a bunch of grapes, or a flock of pigeons are all examples of sets of things. The mathematical concept of a set can be used as the foundation for all known mathematics.

The page on the right is from the lecture notes of a course in Mathematical Logic by Professor Martin Davis of NYU’s Courant Institute of Mathematical Sciences (CIMS) that I took in the Fall of 1969 (emphasis added):

Theorem 7.1. N is inconsistent.

This result should serve to emphasize that a theory whose postulates seem plausible enough can turn out to be inconsistent. Because all of contemporary mathematics can be developed in terms of the notion of set theory, N might have been thought of as an entirely reasonable starting point for the derivation of the entire body of mathematics.

Here is photo of the first page of Halmos’s classic work, Measure Theory:

200712 036
Chaper I: Measure Theory
:

Note that the first word in the first chapter is “sets,” another indication of the fundamental importance of set theory to mathematics.

The Preface to Naive Set Theory begins as follows:

Every mathematician agrees that every mathematician must know some set theory; the disagreement begins in trying to decide how much is some. This book contains my answer to that question. The purpose of the book is to tell the beginning student of advanced mathematics the basic set-theoretic facts of life, and to do so with a minimum of philosophical discourse and logical formalism.

Though one need not know any advanced mathematics, including set theory, to be a programmer, I think that an appreciation for the mathematical foundations of programming will make one a better programmer, and I expect that most skilled programmers know , though they might not first appreciate it, more mathematics than they give themselves credit for.

If there were a Nobel Prize in braggadocio, who would win it?

Though there is no Nobel Prize in braggadocio, there is little doubt who would be the first to win were it to be created.

See the following excerpt from Sun Announces Open Source Community Innovation Awards Program (emphasis added):

About Sun and Open Source

Sun Microsystems made a public commitment to Free and Open Source software (FOSS) and in doing so has contributed billions of dollars, as well as more code, to Free software than any other organization in the public or private sector. In addition to leveraging many industry-wide open source projects, Sun has taken the unique step of opening its core software, hardware and storage technologies and sharing them as Free and open source. This action enables Sun to build its products through the preferred means of co-production and to grow the potential market for Sun products and services by directly attracting users to a free platform, while allowing developers the freedom to identify new opportunities and therefore new markets for the technologies.

I wonder where those billions of dollars that Sun has contributed to open-source shows up in its financial statements. Who got that money? RMS? ESR? BB? LT? RL? GR?

Sure as hell not DS, last time I checked.

The real innovation here is in temerity.

Our Stories Project

I just saw mention of a new project, OurStories.org. It is an effort to collect stories compiled by children worldwide using an XO-laptop about their friends, family and fellow community members.

This appears to be a joint effort of OLPC, UNICEF, and Google.

This is certainly a worthwhile cause, and an example of the kind of application for which the XO is well-suited.

On the other hand, am I the only one who finds the site has more the flavor of a press-release than a site meant for children? For example, the site is currently in English, and the language seems well above the sixth grade level, and does not to me seem well-suited for translation into other languages.

Hmmm…I just read the fine print at the bottom of the web page, including the Terms Of Service. As best as I can tell the project is hosted at Google and the content provided by the kiddies is then sucked into YouTube, a recent acquisition of Google’s.

Sigh, the more things change the more they stay the same.

Moreover, Section B. says:

The Adult Interview Guide available on the Website is owned by Sound Portraits Productions, Inc and may be downloaded and reproduced for educational and personal use only. Contact Sound Portraits at StoryCorps® if you wish to use this Guide in any other manner.

So the XO laptops haven’t yet arrived, and we are already seeing commercial tie-ins trying to extract money courtesy of the content provided by the children on the far side of the world who will be recording these stories.

Well, at least the site is providing detailed education about the U.S. legal system, to wit this language near the end:

You understand that when using the Our Stories website, you will be exposed to content from a variety of sources, and that the Our Stories website nor Google is not responsible for the accuracy, usefulness, safety, or intellectual property rights of or relating to such content. You further understand and acknowledge that you may be exposed to content that is inaccurate, offensive, indecent, or objectionable, and you agree to waive any legal or equitable rights or remedies you have or may have against the Our Stories website or Google with respect thereto, and agree to indemnify and hold the Our Stories website, Google, its Owners/Operators, affiliates, and/or licensors, harmless to the fullest extent allowed by law regarding all matters related to your use of the site.

And you thought the XO was just about educating children …

Building your own Linux Fedora computer using the ECS GeForce 6100SM-Motherboard

I wrote a piece in September, 2007, about building your own Ubuntu computer, Building your own Linux Ubuntu computer using the ECS GeForce 6100SM-M motherboard.

Since the XO laptop runs Fedora, I have juast converted this box to run Fedora 8. There were no problems, so I’m publishing the same post under this title in case someone is searching for help building their own Fedora Linux computer.

By the way, the “Build Your Own” post has proven quite popular since its publication last September. It has drawn over 2500 views to date and is consistently among my most viewed posts.

OpenDS: Observations from an open-source project maintainer/screwup

[Other posts on this topic: first previous ]

L’Affairre OpenDS continues to make the rounds of the blogosphere. My modest efforts to date include the following, in the order published:

Recent contributions to this contretemps include the following:

  • Mike Dolan’s Comparing “open source” projects? Start by asking why does the project exist
  • Redmonk’s Michael Coté’s link to Mike’s post, links for 2007-12-08, with Michael’s comment, “Control vs. no control when a company does open source.”
  • Redmonk’s Stephen O’Grady’s link to Mikes post links for 2007-12-09, with Stephen’s comment, “very interesting piece by mdolan; a bit cynical towards Sun, as usual, and i do think comparisons are possible between projects managed under different governance models, but there’s a lot in here that i agree with. be interesting if he went introspective.”

Additional observations can be found via the comments to Mike’s blog post:

Both Mike Dolan and Sean Dague are IBM colleagues, though of course their comments, as are mine, are being posted as personal views, and are not intended in any way, shape or form to reflect the opinions or strategy of our employer.

As best as I can tell, only Sean and I have had actual experience starting and running an open-source project. Sean only offers a brief comment that Mike’s comment makes some good points. I agree with Sean, and hope he takes the time to give some of his own thoughts in a future blog post.

Here are some of my own further observations, based on my experience starting and running an open-source project, Jikes.

What is an open project?

There are two kinds of “open” projects. The first is the publication of software in source code form under a license approved by the Open Source Initiative (OSI).

The second is the publication of content, usually not computer software, under either an OSI-approved license or a Creative Commons (CC) license. An example of an open project that does not publish software can be found at Groklaw.net. If you look at the bottom of the page you will find that the content is licensed under the CC Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

Some open-source licenses explicitly allow for the inclusion of content that is not software code; for example, the Eclipse Public License v1.0, which says in part:

a) in the case of the initial Contributor, the initial code and documentation distributed under this Agreement,

Since our main purpose here is to study how projects are governed, not the form of the content they distribute, I take “open-source” and “open-content” projects to mean the same thing.

Why does an an individual or organization start an open project?

The Jikes project came into being for many reasons:

Jikes was one of the first programs that IBM made available in binary form for Linux, in the middle of July, 1998. The publication of this binary version was followed by exponential growth. Before the announce we had been averaging about 20 downloads/day. We got several thousand within the next few days.

Soon thereafter we got requests, which we had expected, that IBM publish the code in source form. I told our users that while I didn’t think IBM would approve the release of the source code, I would make a good-faith effort to present the case to IBM management.

The first reason was that users asked for it.

The second reason was that I saw this as a challenge, and I wanted to see if I could convince IBM to release the source code.

The third reason was that I wanted to buy some more time for the project, as I knew that if Jikes were to be released in open-source form, then we would probably be given more time to work on it.

The fourth reason was that I knew that Jikes was not going to be part of any IBM product, so that unless I got the code out in open-source form, then it would wind up on some hard disk in IBM Research in Hawthorne, and no one would ever know what a great job my colleage, Philippe Charles, had done in designing and implementing it. (I wrote part of the code; he wrote most of it.)

Another reason was I wanted to get Philippe some of the recognition that was his due. He had then worked on Jikes non-stop for over two-years, in the most sustained, high-quality programming effort I had ever personally witnessed (I still feel that way).

The proposal I wrote offered a business reason for IBM to release the code, and I will discuss this below.

Finally, I don’t really know the reason Jikes went out in open-source form. I do know it was approved by management. Whether it was because they accepted my business case, or didn’t pay proper attention, and just did it on a hunch, remains an open question.

This is a key point: it doesn’t really matter why an open-source project gets started, just that it does.

Initial publication of open-source code?

Once you, as an individual or on behalf of your employeer, decided to publish code in open-source form, you have several options.

As I have stated earlier, the best strategy, at least in my view, is to give the code to someone else, and let them take over its governance. For example, no matter how good you think you — or your company — is, the folks at Apache Software Foundation will do a much better job than you can ever hope to do, so the best option is to give it to them, if they will accept it, and then work under their guidance and auspices.

Some of the lessons learned running an open-source project for company

Ken Coar, both an IBMer and a member of the Board of Directors of the Apache Software Foundation, refers in his blog to his employer as “BigCo.” In the rest of this post I’ll relate some of my experiences and lessons learned running the Jikes project, though I will refer to BigCo, and not just IBM, as I think the lessons learned apply to other corporations, including Sun for example, that initiate an open-source project.

The business case for BigCo to release the source of Jikes was as follows, and was written at a time when BigCo had not yet started an open-source project, back in the days (1998 in my case) when open-source was just showing up on the corporate radar. I argued that if BigCo were to ever engage seriously in open-source activity it had to do the following:

  1. Publish the source code of software recognized as valuable. (It would not suffice to throw just anything over the firewall; it had to be code that would be of interest. In this case, the users had already asked for the code.)
  2. Make the code available under an open-source license, writing a new one if necessary;
  3. Publish the code at a URL ending in “Bigco.com,” to show BigCo was not afraid of publishing open-source code;
  4. Run the project at that URL as an open-source project, to show that BigCo both understood the open-source rules and was willing to play by them.

The last point is crucial, so let me repeat it:

It was not enough to release Jikes. We had to build a project around it, to show we understood the rules and would live by them

This of course required that someone be found to run the project. Since BigCo had never done this before, that meant BigCo would have to place the responsibility for running this project into the hands of a complete novice, fully understanding that this novice would probably screw things up, not only once, but probably many times.

The question then was who would be the open-source project-manager screwer-upper?

That would be me, Dave Shields.

Moreover, I spent a year at this task, and in the process thus became BigCo’s recognized expert in screwing up the management of open-source projects.

This is the main reason I’m writing this post. Though you can learn something from someone who has enjoyed success in a new venture, the best lessons are to be found in close observation of the failures and screw-ups.

Here then a brief history of the Jikes project, emphasizing what went wrong more than what went right, from the pen of someone who was not only SU the “super user,” but also “SU” the “Screwer Upper.”

What is the goal for the project

The project began knowing it would have a limited duration, at least from the point of BigCo. My guess was about a year, and that turned out to be right.

While it would be acceptable to just run the project for a year and see what happened, as that could have shown the BigCo had gained first-hand experience in accepting the responsbility and risk of running an open-source project, my own goal from the start was to have the project continue after BigCo stopped participating in it, so that I not only had to build a community but wanted to build one that was self-sustaining.

This is generally the case. A BigCo starts a project not to provide a lifetime job for some of its developers, but in the hopes the initial seed code will be adopted, expanded, and then taken over by a community not controlled by BigCo.

This is but another way of stating what everyone who has ever engaged in starting, running, or leading an open-source project will tell you.

A successful open-source project requires three things:

  • Good code. Open-source developers have a keen sense of smell. They can smell a rat seconds after trying the code. If the code isn’t good you are doomed.
  • Good leadership. Even if the code is good, you need to show you can manage it well. Ineffective or bad management usually spells doom; the best you can hope for otherwise is that someone with more skills will fork the project.
  • Vibrant, self-sustaining community. Community is all, for users will not put code in serious applications unless they are confident that it is either perfect (which is rarely the case), or has a community behind it with a lifetime measured in years, if not decades. To use open-source code is to place the fate of your code in the hands of the open-source project. Only idiots would place their fates in the hands of idiots. (That’s the theory at least, though most elections prove this is not always the case.)

You must recruit open-source developers

You need to recruit open-source developers to take over the project, unless you are willing to spend the rest of your life working on the project; otherwise the project will die when you and the other BigCo employees leave it.

Code rusts, and sometimes poops, too.

Software is not a stable form of writing. [1] The surrounding envrironment is constantly changing, so to think you can perfect the code and then leave it is as chimera. Moreover, most code has bugs, and you need someone to take care of the poop. Unless you like poop — and I don’t — then not only do you need to attract developers who will do the neat extensions and polishing, you also need to find devlopers to tend to the poop.

Most open-source folks do not trust big companies

Soon after Jikes first went out I started to see comments and such in Slashdot suggesting it was just some sort of conspiracy on the part of my employer. After spending a day or two trying to sort this out by claiming BigCo really had the community’s best interests at heart, I gave up further boasting of BigCo’s sterling reputation, but I did take away one important lesson:

If you are running a project of behalf of a company, accept that most people do not trust companies, and spare yourself the grief of trying to change their minds. Also accept that all they will know of the company going forward is how you act. As is often the case, words mean nothing, character and behavior is all.

As a corollary of the above, it doesn’t even matter what your company thinks the project is about. All that matters is how you participate and run the project.

Most open-source folks don’t care about many of the things that big companies do

I have often dealt with press releases, position papers and such, some of which were prepared on tight deadlines. I try to help as best as I can, but I do keep in mind that most of this kind of work is of absolutely no interest to open-source developers, and it is those developers you need to attract to make a project sustainable. For example, open-source developers do not even know what the Gartner quadrant is, nor do they care, nor do they read InformationWorld and most of the other trade rags. They have better things to do, reading the project mail lists being the main one.

There are open-source “rules”

There are well-defined rules and practices for running an open-source project project, what is called open-source “governance.” If you believe, as I do, that open-source programming is just the application of the scientific method to programming, and thus programming at the highest level, then it follows that the best way to govern a project is to also use the scientific method: peer review; giving credit where credit is due, with extra credit to the first to do something; promotion based on merit and not the arbitrary exercise of power; lack of dogma; willingness to try new ideas; and so forth.

These rules are quite simple. Indeed, they are so simple that the open-source community takes it for granted that you know them. You will get help if you ask for it, but most folks will not volunteer it. After all, why try to help someone who is so dumb they don’t even know they need help?

If you do ask for help you will get it. Moreover, if you make clear that you want to play by the rules, then a lot will be forgiven. It’s ok to screw up, as long as you demonstrate you are willing to fix things. On the other hand, protestations that something is not a screw-up, but a requirement of corporate process, as was recently the case in some obscure change to OpenDS project rules that probably only a handful of Sun employees had even read, will for the most part be met by the response, “The screwup doth protest too much.”

Email is hopeless for resolving disputes

Open-source developers are extremely skilled in email. They can deal with many threads, often at a deep technical level, and are usually much more skilled at this than corporate developers.

Corporate folks, especially those new to the open-source world, tend to bring their culture with them. Attempts to use that culture’s process to run an open-source project will only cause friction, and in some cases needless disputes.

Once a dispute goes beyond the irksome email or two into a full-scale “firestorm,” then wise hands will immediately cease and desist.

Sometimes you have to give a message in person

I once worked as part of a team that was asked develop a presentation that was deemed important. When we were done we sent it off as an attachment to the responsible exec, saying it was ready for distribution via email to the execs for whom it was intended.

We got a response saying, “Some messages are too important for email. If we just send this out it will be ignored. Find out the key folks, the key sites, schedule some meetings, then get on a plane, and deliver the message in person.”

This explains why I suggested in the post, “Time for Sun to make a call,” that only a public statement by a senior Sun executive, or a direct face-to-face meeting, could rescue OpenDS from its current sad state.

You don’t need am ombudsman, you need a sheriff

I have mentioned in the past that it is useful in large projects to have a “sheriff,” an employee who is also a recognized expert in open-source. The sheriff can serve as a bridge between the open-source community and the corporate developers, most of whom will be dealing in an open-source project for the first time. The sheriff can buy time while the firestorms are put out, the feathers unruffled, and tempers cooled down, so that everyone can be back to work.

This role can also be thought of as similar to that of an ombudsman, but the ombudsman needs to be someone who is a recognized expert in running a project. Morever, the notion of “ombudsman” itself carries it a connotation of authority, something that itself is anathema to well-run projects; see for example, Yogi Yarns — On forking and plenipotentiaries

[I’m going to draw this note to close here, though I could go on. I started a post, “history of an open-source screw up,” several days ago, but as it kept growing and growing I realized it might best be published in serial form, and so offer this as a first chapter in that larger work.]

Notes:

1. Don Knuth’s Tex is a notable exception, as is Knuth himself.

  • Pages

  • December 2007
    M T W T F S S
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • RSS The Wayward Word Press

  • Recent Comments

    daveshields on SPITBOL for OSX is now av…
    Russ Urquhart on SPITBOL for OSX is now av…
    Sahana’s Respo… on A brief history of Sahana by S…
    Sahana’s Respo… on A brief history of Sahana by S…
    James Murray on On being the maintainer, sole…
  • Archives

  • Blog Stats

  • Top Posts

  • Top Rated

  • Recent Posts

  • Archives

  • Top Rated