Articles / A Year of Learning

A Year of Learning

Leading an Open Source project is no simple task, as many of you know firsthand. Trying to manage all the bug reports, keep the developers in line, and stay on top of the mailing lists while still trying to have a life can be a very difficult, yet most rewarding experience. I'm the founder of the SquirrelMail project. It's safe to say that when we started the project over a year ago, I had no idea what I was getting into. The above-mentioned qualities were nowhere to be found in my arsenal. I've learned a lot of important lessons over the past year, and I thought I'd take some time to share them with you. I'm definitely not the source of all wisdom on the subject (for that, see "The Cathedral and the Bazaar"), but one thing I can say I know for sure is that this past year has been one of growth and learning for me.

Personal Involvement

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.

The Power of the User

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.

Learn from Mistakes

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.

Time Management

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.

Recent comments

12 Jul 2001 00:46 Avatar phutnick

Re: Wow! What can I do?

> Now it's time for me to get involved.
> I feel that I should now try to give
> something back, but I haven't programmed
> in years. So what does a fairly
> experienced Linux user do to help??? I
> have replied to a couple of Tester ads,
> but they have reuired skills I did not
> have or have not used in a while.


Easy. Find a couple of projects that are personally interesting to you. Then subscribe to the devel list, and lurk. Then, read the code and start hacking.

If it is in your blood, you'll be submitting patches before you know it!

-Peter

25 Mar 2001 15:56 Avatar mpwilson

Uggh, it's about marketing...
Anyah,

I had some terrible difficulty responding to your

comment. But that seems to be the trend.

[Anyone know what's up with that?]

The Open Source arena is so amazingly hot

that if you're not getting any responses at

all you've almost definitely got a marketing

issue.

People either don't know about your project

or find the title & blurb uninteresting enough

to not pursue it, or simply feel that it just

doesn't apply to them (almost the same

thing.)

So I figured I'd take a look...

I haven't pulled down the code yet but I

noticed that you describe Tech Tracker

as a "web-based tracking system." I had

to get to the homepage before I found

out what that actually meant. I would

recommend putting some work into your

project blurb on freshmeat.

- Who "could" it help (rather than who

was it designed to help.) and what's your

target for the project itself.(Where do

you want it to go tomorrow ;) The

part about "...to support the needs of a

school system's tech support staff.."

would've turned me off because I'm

just not that target audience. Your

system is much too widely scoped

to try and market it that way (yeah,

like I'M the expert.)

- Definitely put some of those bullet

items from your web page (in the

"Presently, it provides:" section into

the freshmeat blurb.

- Add the implementation language.

If you're looking for help (and

from exploring the demo a bit I

see no reason why you shouldn't

get it) from developers, you'll need

to interest them in the platform

itself.

Hope this helps. Do feel free to tell

me to just go shove :)

- M

Oh, I played around with the demo a

bit. Pretty cool.

19 Mar 2001 11:22 Avatar jamesoden

Feedback even negative is appreciated.
I recently (within the last six months) put my own application out there, and I can completely attest to the necessity of the administrative side. Unfortunately, I have experienced just the reverse of what many of you have experienced. I have had next to zero feed back from the Open Source community, and zero developers come along and ask if they could lend a hand. At first I even looked forward to a comment like:

your code sucks, go away!

but, instead there was only silence. Lately, I have stopped

worrying about it, and just keep, I hope, improving my code base, but I still hope for some intrest (even negative, because that tells areas where I can improve or change).

So I guess having said the above, I have must pose the question...How does one interpret silence?

12 Mar 2001 05:28 Avatar x400

Re: Wow! What can I do?

> It wouldn't let me reply to the above
> message, so I replied to my own.
Yep, I do to that sometimes.
It helps in few ways.


> Linux....It just IS!

You got that write for sure.
:-)


12 Mar 2001 00:29 Avatar RedHatRob

Re: Wow! What can I do?
It wouldn't let me reply to the above message, so I replied to my own.

I can, when I make myself, write fairly well. So writing documentation is not below me. Somebody has to do it!

Besides, you learn alot writing documentation. Including getting a basic understanding of what you are writing about, you also get the organizational experience.

I guess I'm volunteering to write documentation.

I can write in several formats & styles, and am a willing pupil as well as a learned expert.

So, developers wanting to acquire someone willing to do some of the menial stuff, and capable of doing it in an intelligent fashion, I'm you're guy.

RHR

Linux....It just IS!

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.