Archive for November, 2007

I have contributed to open source projects ever since I knew what the term meant. I didn’t see the real benefits until I created my own projects, or completed modules for existing projects. Now that I have been doing that for over a year I want other developers and their employers to know the joys and benefits of developing open source projects.

There is an obvious intrinsic benefit of creating something and sharing it with others, and community collaboration, but that’s so surface level I won’t mention it anymore.

When you work in any job that has more than one technical resource, you divide responsibilities. You are often given the responsibility that you are strongest in so that the company can benefit. You might not be in the project from the start or carry it until its finished. You block out your own ideas on the project in order to knock out the next ticket, task or requirement. Over a long period of time, you have done a lot of work but all of the identifiable accomplishments are that of the team. This is all very necessary in order to accomplish an end goal, but what I’ve found is that some smart side tracking can be good overall.

In contrast to the typical workplace; When you create your own project from start to finish every idea is yours. The ones you implemented and the ones you did not. You start to get a new perspective for what decisions need to be made to complete a product at the expense of some lost ideas and compromising standards. As you are developing, you might think of one of the forums you were 0n that was criticizing someone else’s application, so you rewrite half your code just to avoid that same person complaining about yours (You could do this endlessly). As you are developing you find out how much of a niche you’ve been in when it comes to the complete process. You have to create the database, the functions, the presentation etc. there’s a lot to learn in each niche and also a lot to learn in how they work together. You start to gain an understanding for why the DBA needs to be involved early, and why the presentation guy needs to know all of the peripheral components that he’s not working on directly. When you have a product that you think is complete, you go to publish it and realize how far you really have to go. You still have to assign a starting release number and think of a reason it is and how you will progress it. You have to write the documentation. When you get to the install portion of the doc you admit that you would not follow such a long and complicated process, so now you need to write some install routines. Now you have an actual complete package, what will you do with it? If you use other apps as a benchmark you need your own webpage, screenshots, forums etc. By the end you are a bit sick of how much effort there is beyond creating the core product, but hopefully you push through to be proud of something you can release.

By the time you release your project you have learned a lot of things you otherwise would not have had the opportunity to. You put some extra thought and effort into it knowing you’d have your name next to it and people can be rather heartless when review the free software they download. Most importantly, you gain a new perspective for how everything fits together, and logical explanations for why things turn into the messes you work with normally.

After you release it you can get some very good feedback in how to improve you development skills, presentation, etc. You have to be stoic about the process and expect for a few people to just flame you in a non-helpful manner, which in itself is a very useful skill.

From an employers perspective, they have an employee with enough thought to create their own product, drive to implement it and mental agility to learn all the areas necessary to complete it. It’s far better than a training seminar, or college course and there’s something tangible to show for it at the end. If the employer likes the project they can claim it as their own to drive traffic and credibility. If they become a user of the application they will immediately appreciate the completeness of the package including documentation and install routines that are so often missed in internally developed apps. This is something that Google does as a practice and many of their very popular applications were born out of encouraging employees to work on personal projects that were approved. I believe that this is of such an obvious benefit to employers that they will eventually look for employees who have done these projects in the past, because it can tell you so much more about them as a developer than any resume.

Good luck in your Open Source apps and getting them approved!