I awoke yesterday morning to the radio and was stunned to hear of the death of Mtislav Rostropovich, who for me was unquestionably the greatest cellist to play in the past century. His death was not an unexpected one, as he was 80 years old, but the sense of loss is still palpable. I feel as if I lost a close friend.

I first heard Rostropovich live in concert when I was 8 years old. He travelled to perform at the Wharton Center in East Lansing, Michigan. My parents could only afford the cheapest tickets, and so we sat literally in the last row of the upper balcony. My Dad brought a pair of binoculars so that we could actually see what he was doing. I had been playing the cello for only a year at the time, but I still remember vividly watching him perform the "Dance of the Elves" by Popper as an encore. We were so far away from him, his bow was already a third of the way to the tip when the sound would reach my seat! Soon after, I discovered his recording of the Dvorak Concerto and Tchaikovsky Rococo Variations with Herbert von Karajan and the Berlin Philharmonic. This recording, made in 1969, was and is my single favorite recording of anything. There is a moment right at the end of the 3rd movement of the Dvorak written shortly after Dvorak's sister had died which features a wistful, almost nostalgic sense of peace and pain. The cello climbs up through 3 phrases to a high B trill. Right after this moment, Rostropovich creates the most incredible sense of loss between the high B and the following note, an A, that I have ever heard or imagined. It is quite simply the most incredible moment of all Western music, recorded or live, that I have ever experienced, and there are no other cellists who even come close to the understanding of the universe of emotion in that simple whole step shift.

My contact with Rostropovich continued to be abstract until I attended the Tanglewood Music Center in 1998. That summer, at the very end, Rostropovich gave a masterclass. I was selected along with two other cellists to play for him. For my repertoire, I chose to perform the first movement of Prokofiev's Symphonie Concertante, a piece written for Rostropovich. In the class, I was very surprised to see that Rostropovich was a very short man. On stage, he looks to be at least 6 feet tall because of the tremendous energy and intensity with which he performs. I had worked on the Prokofiev with two different teachers, Anthony Elliott at Aspen the previous summer, and Norman Fischer at Rice University, where I had just completed a Bachelor's in Music, and so had studied the markings in the score quite diligently, choosing to change some of the bowings in the effort to get better projection. The first thing Rostropovich said was that I needed to play the bowings in the score, that splitting them was like bad breathing in singing. Fortunately, I had learned the piece with the original bowings, and was able to immediately play with them.

Some people think Rostropovich's sound is due to his possession of the most incredible Stradivarius cello, the "Duport" Strad, but he handily disproved this theory in the masterclass. Shortly after starting, Rostropovich walked on stage, grabbed my cello and began to play the Prokofiev, talking the whole time about what he was looking for in bowing. Standing a few feet away from him, I was amazed to hear the Rostropovich sound coming out of my cello! I most decidedly do not possess a Strad or anything near to one, having had the opportunity to play on a Strad for a month while studying at Juilliard.

After instructing me on how to bow the piece, Rostropovich sat down at the piano and began to play - from memory - the orchestral reduction of the Symphonie Concertante to accompany my attempt to absorb his suggestions. After my half hour session was over with him, he grabbed me in a big bear hug and gave me a scruffy kiss on the neck, as was his custom, posed for a photograph and then signed my copy of the Prokofiev score. Unfortunately, the photograph did not turn out, but the score is one of my most treasured possessions.

It was the pinnacle of my life as a student. After 13 years of having my life as a musician and as a human affected by this man, I finally was able to play for him and it was much more than I had hoped for.

I only wish that I could have had the opportunity to be in the right place at the right time to perhaps have studied with him more extensively

Tobias Schlitt posted an interesting list of rules on how to get started in an open source project. This got me immediately thinking about an interesting trend I've observed since I dipped my finger in the open source well. Often, helpful tips on what to do when joining a project are provided by experienced open source developers for the newbies, in the effort to make things easier for all.

However, even more important, in my view, is how an existing open source project reacts to an influx of new users. Do we chide them for lack of knowledge? Set up a mesh of obscure unspoken rules? How about yelling RTFM triumphantly? Marking a bug as bogus with a sarcastic joke? I am personally guilty of all of the above in my time.

What surprises me in retrospect is that I didn't really recognize the point where I crossed the line from simply contributing to an open source project to when I started running it. The fact is, when you don't have the karma (to borrow Toby's definition), nobody cares if you make a little joke here or there. Once you are a representative of a project, what you say and do matters, and things can get blown all out of proportion. So, here are a few rules for people "with the karma" that I've learned.

You might be thinking "I don't run an open source project" but in many cases, you become a representative (and therefore one of the people who run it) of the project the instant you achieve enough karma to commit code to CVS, so this post applies to just about all of us!

1. If you must criticize, criticize with a gentle and humble tone

I can't emphasize the importance of this rule too much. It takes courage to approach an open source project and to suggest that these people who have been around doing this for much longer should change something, especially since chances are the bug report/suggestion/whatever will sound stupid if the user is an outsider. In addition, users who are derided have been known to go to extraordinary lengths to "get back" at the project that shunned them, even if no shunning was intended. If you have to mark a bug as bogus, I've found it is not only nice but necessary to apologize for the inconvenience, and to provide a complete explanation. If you can't provide one, re-examine your assumptions: maybe there is some merit to the bogus report. In my experience, nobody complains if you bump a bug to a feature request and pop it to the next release cycle. If you have to say RTFM, don't. Just post a link to the manual page and a brief sentence describing the technical details of the solution the user needs to use, without implying anything about the user's intelligence, preferrably without any emotional content. You never know, this user may turn out to be your most valued developer a year or two down the line

2. Unless the evidence suggests otherwise, assume that users you don't know are not interested in committing to the project

The single most annoying thing, in my experience, is when a developer pops up out of nowhere and offers to help maintain a package, even emailing back and forth a few ideas, only to disappear when karma is granted. In my experience, developers look at open source a bit like relationships: easy dates don't always make the best spouses. The work it takes to get to know a project, to develop trust through the quality of code, to basically endure a trial by fire instills a well-deserved pride from the developers who survive it, and garners a longer term commitment. By all means, accept help from developers, but if a user isn't being persistent, reporting bugs, requesting new features - and providing patches - it means they would rather you fix the problems for them. Before I understood this basic truth of open source, I was very frustrated finding developers to help out. Now, new devs are popping up with a surprising regularity.

3. Despite the evidence, it's probably your fault

If more than one user asks the same question, even though the manual is there, and there is an FAQ entry, this doesn't necessarily mean that the users are all stupid. Most likely, if you browse to the project homepage, and there is no obvious way to search for answers, or the answer is buried 6 clicks deep and requires prior knowledge of manual structure to access, it's probably your fault. Use the innocent "dumb" questions of average users to gauge usability issues with the project. You might find that there is a simple restructuring that will eliminate the annoying questions and attract better developers in one wonderful patch set.

4. Follow the rules you apply to those with lower karma!

The temptation to abuse your power is great in all positions of power. Humans like to do things that others cannot do, even if it's simply because it is a pain to follow the rules. This, by the way, should tell you something about the rules (see rule 5). If you don't follow the rules you set for others, you are corrupt. It's unfortunate, but not complicated, and almost impossible to dig yourself out of. Corrupted people lose community standing and damage the essence of the project they are running, even if their intentions are generally good.

5. Don't apply new rules casually, and simplify if possible

Certainly, as an open source project grows, rules can be useful for creating structure, but often the rule would be unnecessary because the infrastructure (communication methods email/wiki/forum, bug tracker, manual) is responsible for the problem. For instance, there was a lot of griping on pear-dev about accepting/rejecting packages before Toby Schlitt coded the PEPr mechanism. Many political solutions can be fixed with a clever technical implementation. However, try not to "legislate" through your technical solutions. For instance, the PEAR installer enforces a number of PEAR-specific coding conventions in package.xml, and does so more in the latest 1.4.x/1.5.x installer. Although helpful for PEAR developers when releasing through pear.php.net, these technical solutions to a political problem are in fact now causing more trouble than they are worth for PEAR channels outside of PEAR.

6. Assume everything you ever say will become permanent and don't say things that will come back to haunt you

Not sure this needs elaboration. Let's just say stupid flame wars, personal attacks, cursing - these all fall under this rule's umbrella.

7. People like to improve their code, and like coding standards

Many blog posts I have read recently say they "hate" this or that aspect of some other project's coding standards. I used to get into the religious battle (for me it was the added bloat of spaces vs. tabs - until I got high speed internet), but the fact is coding standards make it more fun to code. People might complain about them, but it's a passing thing. Don't even insist on them, just calmly correct the mistakes and even the most fiery zealots will come around to reason. Suggestions to improve code are universally well-received if delivered with respect. Honest!

8. Assume there will be politics, and plan for them

As I said in a comment to David Coallier's blog post today, ideas are the currency of open source, and politics is the commerce. Without a free and comfortable exchange of ideas between very different view points, you don't have a healthy project. Most open source projects start out with a dedicated core of like-minded developers, and so it appears as if there are no political issues at all. The truth is that politics need to be factored into all planning. Design a clear and limited mission for the project, create a clear governance system with room for flexibility as the project expands, and for God's sake try to keep the administrative details out of the way of the coding!

9. You have two audiences: developers and users

There is an inherent conflict between the needs of developers, who wish primarily to code cool stuff, and users, who wish primarily to not have their crap blow up on the live site. Users usually get mad when you break compatibility, developers get mad when they have to keep it. Users get mad when there's no documentation, developers get mad when they have to write it. You get the picture. Seek strategies to bridge the gap between these two disparate audiences. The PHP project has a fantastic documentation project consisting primarily of people who do not actually develop the PHP source, and they co-exist quite peacefully and actively. Think along these lines, and jump at opportunities to help out users without alienating developers.

10. Dream big, baby. Plan for the future

People like to be involved with cool, life-changing things. Don't sell your project short, write great code, and solve intractable problems with beautifully simple, eloquent solutions, and do it all from the comfort of your living room. To put it another way, unless you are some kind of freak, you won't have the energy to sustain the initial push behind the project all by yourself for more than a few years. Make sure you're planning ahead for your inevitable retirement or at least scaling back involvement, and seek out proteges to take over the project. The more attractive the project is, the more likelihood you will find that magical dreamer who will carry the torch off into the open source sunset.