Nir Aides, the author of the excellent
winpdb debugger, sent me the following email on September 21, 2008, so I asked him if I can copy his email and reply in form of a blog post (so that other people can comment and join the discussion) and he agreed. It took me almost a year to reply, but I made it. :)
Hi Ondrej,
How are you?
I am about to publish a new free software project, a new simple PHP framework, and I am interested in your advice.
You started SymPy and were able to make other people join you and develop it with you.
How did you do it?
How did it happen?
Did you actively call for other people or they spontaneously showed interest and joined you?
Are the other major contributor people who were your friends before you started the project?
Did you need to create or manage the project in a particular way to make it attractive to other people?
Are there things you are aware of that promote collaboration or demote it?
I was never successful in doing the same with Winpdb, which while it became reasonably popular, no one has ever joined me to develop it, except for a notable tutorial contribution by Chris Lasher which was developed independently.
Now with the new project, I am wondering what are my chances of making other people try it and take it on. On the one hand it is a new and fresh code base in an interesting field, on the other hand, why would anyone bother to spend their energy on this new project when they have Symfony or Drupal?
What do you think?
BTW, Ohloh believes you have a median of 19,000 lines of changed code per month since the start of their log. Can this be true? Is this humanly possible? According to it SymPy has over 1,000,000 lines of code? I can't understand these numbers. Winpdb has about 25,000 lines after 3 years of development. And from my experience 1,000,000 lines of code projects need about 20-50 full time developers to work on for 2-5 years which is about 40-250 man years. And as if this is not enough you are listed as owner in a dozen other projects in Google code and have enough time to become an awarded scientist. How is this possible?
http://www.ohloh.net/p/sympy/contributors/
BTW2, do you still use Winpdb? If you find yourself using it less, can you say what are the reasons, or what it would take to make it more useful?
BTW3, How is SymPy doing?
Cheers,
Nir
So my most honest answer how to run a successful opensource project is: I don't know.
But nevertheless I tried to summarize some of my ideas and experience and some guidelines that I try to follow, maybe it will be useful to you Nir, or anyone else.
First of all, there has to be a public mailinglist (easily accessible), public bug tracker, nice webpage, easy to find downloads, frequent releases (once a month is good, but in the worst case at least 4 times a year) and a set of guidelines to follow in order to contribute. So that's a must, if the project doesn't have the above, it's almost impossible to become successful. However, that is just a start, just a playground. There are still many projects that have the above and yet they totally fail to attract developers.
So I think the most important principle is that I always think how to employ other people in what I do. If I have some plan in my head how to do something, e.g. how to move some things forward, I always create exact steps and put it to issues, or our mailinglist, so that each step can be done by someone who is completely new to sympy. So I try to look at things from other people's perspective and think -- ok, I quite like this SymPy project and I'd like to get this done (for example a new release, or something fixed, or implemented), but I have no idea how to start and what exactly needs to be done.
So what I try to do if someone comes to our list and asks for something, is that I create a new issue for it and think how I would fix it if I had time. Then write the necessary steps in the issue and invite the submitter to fix it and I offer help with explaining anything and guiding. Now there are two things that can happen. Either the submitter has time and a will to go forward and in this case he starts wrestling with it and whenever he has some code or a question, I need to find time, review it and offer some way out. Or the submitter is too busy, in which case the instructions simply rest in the issues and the next time someone asks for the feature, the instructions are already there. I don't have estimates how frequent either case is.
When I am working on something myself, I try not to code privately, but also put up issues first and put the steps needed in the issues, so that it's easy for other people to join in.
In general, the most precious value for me is the fact that someone else had to sit down at his computer and wrote the patch. So I do everything possible to get new (or more) people interested in the development. Some people think that only super programmers can do a decent job and it's useless to invest time in people that may just have started with Python. They are wrong. Among the SymPy developers (around 65 people total have contributed patches so far at the time of writing this post), we have all kinds of people. We have people from high school, we have a retired US army engineer, we have physicists, mathematicians, biologists, engineers, teachers, or just hobbyists, who do it for fun. Unfortunately, we do not have many women (I think no patch that made it into sympy was contributed by a woman, but I may be wrong), so if anyone has any ideas how to get more women involved, let me know (I know we have several women fans, so that's a good start:). We have people whose first open source project they ever contributed to was sympy and people who are new to Python.
Many times the first patch that a new potential developer submits is not perfect, usually it's faster for me to write it myself, than to help with the first patch, however my rule is to always help the submitter do that. Sometimes he sends a second patch, or a third, and usually it needs less and less work on my side and it already pays off, because he is then able to fix things himself, if he discovers a bug and sympy has just won a one more contributor.
So I came to the conclusion that all that is needed is an enthusiasm. You don't even have to know Python (as you can learn all these things on the way) and you can still do useful things for us and really spare our time.
To answer another question from Nir's email, SymPy has about 130000 lines of code and another about 20000 lines of tests, so I think those stats are wrong. Also the changed lines of code is in my opinion wrong, we usually have about 250 new patches per release (this depends how often we release and other things).
Yes, I am involved in couple other projects, e.g. Debian, Sage, ipython, scipy,
hpfem.org (and couple more), basically everything that has to do with numeric simulation and Python, but my activity there varies. The most time consuming thing in the last couple years was definitely school, I was finishing my master in Theoretical Physics in Prague and then moved to the Nevada/Reno and I just finished my first semester here at PhD in Chemical Physics, and sometimes it was just crazy, e.g. I finished teaching at 7pm and instead of going home and sleep, I stayed in my office, fixed 10 sympy issues that were holding off a release, finished at 1am, went home (by bike, since I don't have a car yet), slept couple hours and then did just school again for a week, other people reviewed the issues in the meantime, and then I made the release (instead of sleeping again). In the last semester it was not unusual that I got home at 1am every week day, then slept most of Saturday to catch up, on Sunday I did some laundry and shopping, and the rest of time I did grading and homeworks for all my classes and teaching, no time for anything else (e.g. no friends, no girls, no rest, no hobby, no opensource stuff, nothing). So sometimes one has to work pretty hard to get through it, but fortunately it's behind me finally, if all goes well, I should be just doing research from now on and have a real life too. Also I am sorry I didn't manage to reply sooner. :)
To answer the other questions:
Are the other major contributor people who were your friends before you started the project?
No, not a single major contributor was my friend before I started the project. Every single one of them become a developer using the procedure I described above, e.g. first showed on the list or in the issues, and maybe even the very first patch was not a high quality one (and if I was stupid and arrogant, or didn't see the big potential, I would just ignore them). But when given a chance, they became extremely good developers and sympy would simply just not be here without them.
Did you actively call for other people or they spontaneously showed interest and joined you?
I very much encourage everyone to contribute, but the initial interest must be in them, e.g. they at least have to show around the mailinglist/issues, so that I know about them. But once I know they are interested in some issue, yes, I try to invite them to fix it, with my help.
One observation I made is that I have to always think in the spirit "how to earn new money, not how to spare the money I already have", e.g. when applied to sympy, how to get new developers, how to develop the new great things etc. Even if I am super busy as I was, I still have to think this way. Once I start thinking how to conserve and preserve what we already have, I am done, finished and that's the road to hell.
If I am open, positive, full of energy, I can see people joining me and we can do great things together. It probably sounds obvious, but it was not for me, when for example some people I worked with, started their own projects, when I got busy, and started to compete, instead of helping sympy out. And I felt betrayed, after so much work that I invested into it and started to become protective. And then I realised that's wrong. I can never stop other people do what they want to do. If they want to have their own project, they will have it. If they don't want to help sympy out, they won't (and what is more important, there is nothing wrong with either of that). It's that simple and being protective only makes things worse.
There is also a question of the license that you use for the project, e.g. one should basically only choose between BSD (maybe also MIT or Apache), LGPL and GPL (there are also several versions of the GPL licenses). Unfortunately the fact is, that there are people who will never contribute a code under a permissive BSD license (because it's not protecting their work enough) and there are also other people who really want to code to be BSD (or other permissive license) so they can sell it and they don't need to consult with lawyers what they are or aren't allowed to do and also so that they can combine it with any other code (opensource or not). It also depends if one wants to combine (and distribute) other codes together. So choosing a license is also important. I believe that for sympy BSD is the best and for other projects (like Sage) GPL is the best and one has to decide on a case by case basis. For Winpdb, I would make it BSD too, since you can get more people using it.
To conclude, SymPy is a little more than 2 years old, and it has been a great ride so far and more things are coming, e.g. this summer we have 5 Google Summer of Code students and people are starting it to use in their research and we plan to use it in our codes at
our group here in Reno too, so things look promising. I am really glad, we managed to build such a community, so that when I am busy, as I was the last semester, other people help out with patches, reviews and other things, so that the project doesn't stall and when I got rid of my school duties now, we can move things forward a lot.
So maybe you can get inspired by some of the ideas above. I am also interested in any discussion about this (feel free to post a comment below, or send me an email, or just write to a sympy list about what you think).
In a service provider environment it is often required by customers to support old server installations for much longer than it is recommended by vendors.
Recently I had to move some Xen VPSes running Debian 3.1 to a modern Xen host running lenny and the 2.6.26 kernel. Since Xen is a FPOS and has been unable for years to maintain a stable ABI, I always use in the domUs the same kernel version of the dom0. The Debian Xen kernels require using an initramfs to load the paravirtualized block device driver and mount the root, at least. This would usually not be a big deal, but in this case breaks the VPS because the lenny version of udev is started in the initramfs and the system has either no udev or the old sarge version. The most immediately visible effect is that /dev/pts does not exist, which makes ssh less than useful. This is my solution:
This post is being made from my EEEEEeeee PC, using a 3G modem plugged into the USB port. The fact that I'm sat on my sofa, within easy reach of both a network cable and multiple WiFi access points is irrelevant!
I started my adventure yesterday evening, getting pretty annoyed along the way that that it wasn't just plug and go. It turns out I was suffering from two problems:
I've followed the advice of 
Because of the 
Thank you for your help.
We got back from our brief visit to Canada last night. We had a great time,
Vancouver and Victoria were both very nice.
YVR (Vancouver Airport)
This airport has to win the award for nicest airport I've seen. Clearly they
pulled out all the stops in preparation for the Winter Olympics next year.
The airport is very bright, airy and open. Before you even hit the
immigration line, you pass through a couple of water features, some
indigenous art, all of that jazz. Immigration is done in the open in a huge
hall, instead of in the dark bowels of the airport, which was a pleasant
change from the usual US airport immigration experience. (That said, Houston
airport had a pretty nice immigration experience). Oh, and it was blanketed
with free WiFi, which was a nice touch.
Ferry to Victoria
The brief geography lesson I got was that Victoria is on Vancouver Island,
and Vancouver (the city) is not on Vancouver (the island). Go figure.
Getting to Victoria from the airport via 
After years of being a dedicated KDE user it seems like it s finally time for me to go back to Gnome. I once tried KDE 4.x from the Debian experimental branch knowing that it s probably unstable and will require a lot of patience. But I was willing to report bugs and dive into new things.
It didn t take long though to find out that graphics were extraordinarily slow with the new desktop effects . The worst was resizing a konsole (KDE terminal window). It took 25 seconds until the window was resized and redrawn! On the interweb I found KDE developers rant about NVidia who didn t support some special extension they needed. They suggested to get an ATI card instead. (No, thanks, I was struggling with the crappy radeon and fglrx drivers on my new work laptop and am sick of ATI for Xorg.) Or I could use a bare XTerm instead. Yeah, right. So I couldn t use the desktop effects. After all I used the non-free NVidia driver for years and it never let me down.
I don t mind doing without eye candy. But the desktop effects were about the only serious way to switch between virtual desktops. Point the mouse into a corner or edge of the screen and get a zoom-out bird s view of the virtual desktops. Nice but quickly annoying. Besides you had to push the mouse pointer a few pixels into the edge (it s not sufficient to just hit the edge) which means that after 10 desktop switches I had to lift the mouse and set it back on the mousepad.
Another annoying issue is that up to now I can t assign functionality to every key on my keyboard any more. I had a neat trick by having 3 3=9 virtual desktops and use my numpad keys 1 to 9 to page through them. 0 on the numpad opened a new shell window. + on the numpad maximized a window. But now I couldn t assign any of those numpad keys. I pressed the 1 but KDE didn t detect Numpad_1 but just 1 . Guess how useful it is to not be able to type the 1 any more. There is a low-priority bug report for KDE from users who want this fixed but it will likely not happen any time soon. So the only way to switch desktops was to poke on the tiny pager widget in my panel. Yuk.
Not to mention that I couldn t put icons on the desktop any longer. There was just a sissy widget that I could use for that purpose but it didn t work like a conqueror or dolphin at all. It was pretty amusing when in KDE 4.2 there was suddenly a feature to re-enable the old behavior. Let me guess, KDE developers - I wasn t the only user you couldn t persuade of the new paradigm?
Next evil thing was performance. KDE 4 takes ages to load. Simple window managers get me started within seconds. Even Gnome. But KDE takes 30 seconds until it s loaded plus some disk grinding in the background. And memory usage wasn t nice either.
And what finally made me mad was stabilty - or rather lack thereof. Everytime the screen saver ran my kbluetooth module crashed. kmail crashed even more frequently than before. (I loved kmail for it s great customizability and feature set.) plasma (the actual window manager) died at least twice a day. Suddenly the panels were looking ugly or crashing.
As a Debian developer I have to follow the unstable branch on my workstation. And there is no distinction between KDE 3 and KDE 4 any more so a dist-uprade inevitably gets all of my applications upgraded to KDE 4 (plus an hour of manual engineering in aptitude because half of my applications weren t upgraded automatically due to different application names and I had a mixed environment). So there I was with KDE 4.2. I really worked with it for a month. I tried hard to get acquainted to its bloatedness and instability. It s really a nice technological preview of what might be possible in the future. Everything is really automatic. Mounting external media. New ways to find programs (although I m not happy with the new K start menu). Funny effects and nice eye candy. But it s far from the rock solid desktop environment that I was used from KDE 3.5.8.
So there I am on Gnome now. I was switching back and forth. One day working on KDE 4.2 and the other day using Gnome 2.26. And although it makes me feel sad I think it s finally time to say goodbye to KDE 4. I have invested a good amount of time and energy into it - even just from a user perspective. But it s not ready. And I finally need to get some work done. A number of projects suffered from my playfulness (my ispmail tutorial, screenshots.debian.net, debexpo, my kids) and it s time to get back to work. And Gnome was pretty surprising. With compiz I have the KDE desktop effects working (here they really do) and they are all customizable. I can assign keys properly again (even the numpad). Everything is pretty fast and stable. I have replaced kmail and its buggy shared calendar feature by Icedove (aka Thunderbird) with the Lightning plugin. Worked from the first minute and hasn t crashed in a week (just have to remember next time to install libstdc++5 to be able to use Lightning). With enigmail I finally have a proper simple working PGP key management that doesn t die and is buggy like hell like in kgpg. And there s the nice Nostalgy add-on that allows me to file emails into IMAP folder quickly again - a feature that just kmail seemed to support so far. Oh, and I see new mail instantly because Icedove supports the IDLE command while kmail has never learned that neat little trick. The Gnome file manager isn t really great for my taste but it s doing its job (dolphin is just much nicer). It s not as nice as KDE but I had to learn that working and stable weighs more than nice. The hard way. And many things I liked about KDE 4 (like starting a new program with Alt-F2 and having a smart application finder and simple calculator in one) are built into Gnome, too. So why bother.
Thanks, KDE, for the years of fun and service. I ll surely miss you. Get back to me should you grow up one day.
It is curious to see that the eleventh movie in a series is the first to bear the series name with no adornment. It is apt, however: Star Trek is a clear attempt at rebooting the universe and basically forgetting most of the decades-heavy baggage. It seems to me that the reboot was fairly well done, too.
The movie opens with the birth of James Tiberius Kirk, and follows his development into the Captain of the Enterprise. Along the way, we also see the growth of Spock from adolescence into Kirk s trusted sidekick and also into well. Despite the fact that the action plot macguffins are time travel and planet-killer weaponry, it is mainly a story of personal vengeance, personal tragedy, and personal growth. Curiously enough, although Kirk gets a lot of screen time, it is really the personal story of Spock.
Besides Kirk and Spock, we also get to meet reimagined versions of Uhura (I like!), McCoy, Sulu, Chekov and Scott. And Christopher Pike, the first Captain of the Enterprise. The appearance of Leonard Nimoy as the pre-reboot Spock merits a special mention and a special thanks.
I overheard someone say in the theatre, after the movie ended, that the movie was a ripoff and had nothing to do with anything that had gone before. I respectfully disagree. The old Star Trek continuum had been weighed down by all the history into being a 600-pound elderly man who is unable to leave the couch on his own. This movie provided a clearn reboot, ripping out most of the baggage, retaining the essence of classic Star Trek and giving a healthy, new platform for good new stories. One just hopes Paramount is wise enough not to foul it up again.
It was worth it, I thought.