One of the most important lessons I've learned is that when you're a leader of an Open Source project, personal activity and involvement in the project is imperative. I've seen developer activity wax and wane over the course of the development cycle, and a strong correlation exists between developer activity and my personal excitement and involvement in the project. Whenever I took a week or two off, not much development happened. When I was ecstatic about certain aspects of the project, developer response and activity was quite high. It is important that your developers see your enthusiasm so they can share your excitement.
Your attitude toward the project affects the way things are accomplished. Keeping the attitude light is always a benefit. Joking around on the lists or in an IRC room helps build relationships in your team and makes the whole project more fun. What fun is it if it's all business all the time?
Keep in mind that Open Source developers are volunteers. Even though they don't receive monetary reimbursement for their services, there are plenty of ways to repay them. Volunteers thrive on positive feedback. By giving generous, sincere, and upbeat praise to individual team members, you will infect them with enthusiasm. Enthusiasm directly translates into activity and effort put back into the project.
Personal interaction with the developers helps build the group as a team. I've tried to make a habit of getting to know most of our developers outside of the project, talking with them about their other hobbies, their families, and other activities going on in their lives. I think that this has contributed strongly to the close-knit group that we have become. Once everybody knows more about each other, "Luke Ehresman" becomes a person, not just another faceless name on the 'net.
At the start of our quest, I was ignorant of how important user interaction and user feedback would be. A few things have become quite apparent to me in this realm over the past year.
First, and this might seem a bit obvious, advertising and getting your project into the public eye is pivotal to its success. It's possible to have a great project idea, and even a great project in development, but if nobody knows about it, what use is it? Open Source thrives on the fact that many people have their hands on the code and can send feedback to you. Without anybody doing this, you are missing out on one of the major benefits that Open Source provides.
In his essay, "The Cathedral and the Bazaar," ESR states his philosophy that "given enough eyeballs, all bugs are shallow." I've found this to be very true. Countless times, bugs have been discovered and squashed by our developers in a relatively short timeframe. Going hand-in-hand with this is his belief in releasing early and releasing often. I regret some of our extended releases as they seemed to slow development. Most of our releases were months apart. Getting user feedback was difficult when the users didn't have anything new to play with.
Your users are your best friends. Since they have the source code in their hands, they can help you track down bugs rather than just report them. Don't ignore this powerful tool. Work with your users. I've found that more often than not, when a bug is reported, the user will be more than willing to help track down the source of the problem; they just need some help as to where to look.
One of the many wonderful things about Open Source is that we are not constrained to the whims and fantasies of management or marketing. You shouldn't be afraid to rewrite sections of your code, or even start over from scratch if necessary. I've seen this happen countless times with projects.
Take KDE for example. Their 1.x releases were what I would call the "learning phase". They didn't have much direction in where they were going, but hacked together a pretty good graphical environment (note that this is not an invitation to start up the KDE/GNOME wars). Once they released their stable version, they threw it all away and started again from scratch. Over the course of their development cycle, they learned what needed to be implemented and the methods to implement it, and saw it best to start over rather than extend a limited foundation.
Back on the SquirrelMail frontier, we are at the exact same point. Over the past year, we have been putting together the 1.0 version. We are already well through the planning phase of the 2.0 rewrite, which is going to take what we have learned and use it to build something better.
Ah, the mailing lists. They have been my best friends and worst enemies. Being involved in the mailing lists is a never-ending job, but involvement as project leader is necessary! It helps a lot for users to see active involvement just as it's important for developers to see this. While I can't answer every email message that comes my way, I try to make time every day to browse through the mailing list and help out wherever I can. SquirrelMail has an excellent development team, and everybody has been pitching in with the support requests and bug reports on the list. With their support, I've been able to focus my attention elsewhere. The problem I've been facing lately is that it's pretty easy to ignore the lists altogether! However, I've quickly realized that if I do that, I can't keep up with current issues that people are facing with the project.
Tackling new challenges and increasing responsibilities is in my nature -- sometimes I wonder if my parents ever taught me the word "No" -- but delegating tasks is necessary for a growing project. Allowing different individuals to manage various aspects of the project increases the responsiveness and quality of those areas and takes the weight off one person. For instance, Peter Hutnick keeps on top of the mailing lists and updates the FAQ as necessary. Lewis Bergman also monitors the lists and keeps the bug and task list up-to-date. Delegation relieves responsibilities from the primary developer and encourages other people to get involved. It is always good to involve those who are either just learning programming or don't feel worthy to contribute yet by asking them to show their support through activity in the project. More people devoting smaller amounts of energy to a project translates to faster development and a project that doesn't break down just because a single person is on vacation.
Above all else, don't let your project take over your life. Your family, your job, and your real life should have first dibbs on your time. In most situations, an Open Source project is a hobby and should be carefully kept in perspective. The Open Source world is addictive, and can easily whittle away at your time. I'm not saying that you shouldn't be dedicated to your project, but I am saying that there are some things that are more important, and it should be kept in perspective.
A year of learning indeed! As I write this, we are on the brink of releasing 1.0 after 1 year, 2 months, and 11 days. It has been a time of incredible growth for me. Through the project, I've met many great friends. We've all worked like crazy to get SquirrelMail where it is today, and I can say without hesitation that it has all been worth it.