Open Source Project Management Handy Rules ;-)

Let's face it. Most open source projects fail. This is the way the marketplace should work. Ideas and companies fail all the time. While they fail for myriad reasons, one preventable reason for failing is poor project management. Let's face facts. Project management is hard. The job is often thankless and requires a type of mentality not often found in top flight engineers. For certain projects where those engineers have both top flight project management skills and engineeering skills (Brian Behlendorf of the Apache project comes to mind. Brian doesn't claim to have project management skills but he's far too modest).

Project management for open source projects isn't much different than project management for closed source software projects. First off - project management is about organization of information. If your project manager's desk looks like a tornado hit it, he/she shouldn't be your project manager. Very often engineers tend to see project management as a component that can be solved with just the right piece of software or by religously using a tool like sourceforge or MS Project. While these tools can be helpful, very often the tool gets in the way of project management. MS Project's primary purpose appears to be production of pretty graphs and charts which can be handed to upper management. While this may pass for project management at a large Fortune 500 company, it's not. It's the form of project management without actually being project management. If you want your project to succeed, you should learn at least the bare minimum required to actually make your project succeed.

1. Write a functional specification. Specification writing is yet another process with far too much written about it. Once again it is often written in an overly obtuse jargon much preferred by people who are attempting to sound smarter than they actually are. Very often the person that gets stuck writing your functional specification are pretty pissed about and they need feel the need to impress upper management. Fortunately for you this is an open source project and you are management! This also means it needs to be written so you can attract new developers and so your current team can underestand what you are trying to achieve. If you are coming from the traditional corporate world, throw pretty much everything you know out. I would suggest start with Joel Spolsky's four part post on why you need a spec. His advice is right on for any software project. His sections are why you need a spec, what a spec has in it, who should write a specification and tips on writing a painless specification. I would write more about writing a functional specification but quite frankly Joel does such a good job of it and I would simply be re-hashing in a much less interesting way. I suggest you read his posts.

2. Your project needs a core set of high set of developers to start. Without this core of developers consistently contributing. When you first start out, very often your other developers will be in the same room with you. This is pretty helpful initially, you can scribble on white boards, discuss coding approachs, coding standards, you name it. As you work in close proximity your developers begin to develop a mental model about each developers strengths and weaknesses. Hopefully team cohesion will improve as a result. This happens because when human being communicate, they are recieving a whole lot of data on the subconscious level. It might not and if it doesn't you need find which developer is the fly in the ointment and gently suggest another project they might be really interested in. Let's assume however that your team has gelled and your project has begun to get some traction in the marketplace. You are about to add some outside developers who have become interested in your project. These guys have developed a module or two and hopefully will contribute to the core product. So they begin contributing via CVS and discussing things on your mail list (you do have a source repository, bug tracker and commit mailing list right? No - well you should.) However you soon find a flamefest happening on the mailing list and people instead forming a smoothly running team are begining to get upset.

What happened? Well anyone that has spent time on Usenet can tell you. Human communication devoid of any physical proximity fails to capture the nuances of communication and soon these things begin to pile up. Misunderstanding piles on top of misunderstanding. As a project manager when workign with distributed teams, you must find a way to restore the balance and help those bonds form. You could get together on a yearly basis (the BSD project did this and found it helped quite a bit). If the developers are too distributed, web cams (which have much improved in the last few years) can help. Just email, mailing lists or forums don't provide enough context for developers - add another communication medium that will help personalize the other developers.


This post has gotten pretty large so I will continue it with a part two.

Technorati Tags
open source
open source project management

Holiday Ran Late

Sorry for not posting sooner, my holiday, ran a little late. I have a more complete post up in an hour or so. Happy New Year and congrats to the Longhorns.

The final installament of my three part series, "Ten books an open source programmer needs to have on the shelf."

It's been my hope to introduce authors you might not be familar with or books you might not know. So you won't find Eric Raymond, Bruce Perens, or Richard Stallman. While these guys are arguably important people in the free software movement, the books I am have focused on with this list that are actually useful in running a business and an open source project. While the ideological foundations of free software are of supreme importance, if you are already running an open source project, you are undoubtedly are pretty familar with those ideas. So I am trying to offer these as a resource to help your project and business succeed.

• Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity
  
  Ok I have to admit I am a big of fan of Joel Spolsky. While he has spent a ton of time at Microsoft writing software, it doesn't change the fact that at Joel understands the difficulty of writing software, he understands how to do it well and his advice is almost uniformly always right on. Joel know software and software development. His book is full of great ideas whether you run an open source or closed source software company.
  
  
• User Interface Design for Programmers. One of the areas that open source/free software lags behind it's in user interface design. This shouldn't come as a surprise really. User interface design is really hard work. It requires attention to detail and more importantly it requires that the programmer realize that other people use their software. This is especially difficult for open source programmers as they often start their project to scratch an itch. This means that they are usually active users of their own work. This also creates a problem, namely "it works for me" syndrome. As the first user and undoubtedly the more experienced user on your own software, you understand the fundamentals and why you made the choices you did in UI. A new user will not have this knowledge and will come with existing assumptions about UI and how your program should work. This little book has great advice on interface design and will certainly improve your software. I personally believe that UI design is one of the last areas where free software needs to improve. Let's be frank though - only one company has really succeeded at UI design and that's Apple. It's not easy, but just following the basics of this book will improve your software.
  
  
• The Art of Computer Programming, Volumes 1-3 Boxed Set by Donald Knuth. Let's be frank if you don't have these books you are missing a deep understanding of computer science and algorithms. Need a sorting algorithm? Read Knuth. These books are a hard read and they will take time. The journey is well worth and you will come out with a deeper understand of computer science as a result.
  

Choosing the final and most important book that should be in every open source programmers shelf has been difficult. I truly believe that if you are going to run an open source project this book will prove exceedingly valuable.

Producing Open Source Software : How to Run a Successful Free Software Project Ken Fogel who has worked on CVS and Subversion version control systems has produced a great book about the complexities on not only software development but open source software development with it's distributed teams, IRC, mailing lists and project management. he book covers a great deal of ground, giving excellent advice on a wide range of topics: selecting a license; maintaining a mailing list, defect tracking system and version control repository; providing a website; interacting with committers; dealing with technical people; gathering consensus; and understanding important project management concepts. If you only get one book on my list this is the book to get.

Related Posts:
Part One: "Ten books an open source programmer needs to have on the shelf."
Part Two: "Ten books an open source programmer needs to have on the shelf."
Part Three: "Ten books an open source programmer needs to have on the shelf."

10 Books An Open Source Progammer's Must Have Part 2

In Part 1 of this series we covered numbers 10 through number 8 in our hit parade of books every open source progammer should have. One of the real problems I have been having with a countdown approach to these numbers is that I am having a really really hard time ordering these books in relative importance. So I will just provide them in the unordered list format.

• Open Source Licensing by Lawrence Rosen is the guide to understanding the vast number of open source licenses that have sprung up over the past 10 years. Rosen's book educates the programmer in simple, easy to follow English. This especially important for chosing a license for your own project or wanting to reuse the work of another project in your own open source project.
  
  
• Succeeding with Open Source It's nearly impossible to start an open source business with out working with company that's going to have some reservations about open source or simply not familar with open source culture this book can help you educate your potential customers. I would suggest keeping multiple copies to educate a potential customer as a leave behind. This gives a business a methodology for assessing the maturity of an open source project.
  
  
• The Business and Economics of Linux and Open SourceIf you are an programmer deploying open source software in a traditional corporation, you will face a different set of challenges than traditional open source programmer. Integrating traditional open source development into a corporation caqn bring benefits but the process must be managed. He first attempts to provide a functional model for an organization developing software, focusing on enabling an open source process as opposed to a conventional development model. This model may assume a large set of developers and may come out of the blue (it is presented then discussed), but it clearly demonstrates how much of a cultural change it requires to fully reap the benefits from an open source process, and how much other corporate functions such as marketing and HR have to adapt accordingly.
  

Next post I will cover the last four books you should have. These are the most important four books and you will definitely need these.


Related Posts:
Part One: "Ten books an open source programmer needs to have on the shelf."
Part Two: "Ten books an open source programmer needs to have on the shelf."
Part Three: "Ten books an open source programmer needs to have on the shelf."

Ten Programming Must Have Books - Part 1

Well it's getting close to the end of the year. That's when everyone's coming up with a list of one sort or another. I have decided to throw out my opinion on 10 books that should be in every open source programmer's library. Naturally they will be available for purchase in the Thinking Monkey Shop. This list isn't definitive, not complete at all and will certainly reflect my personal biases. So this means NO complaints. If you don't like the list, please feel free to compile your own list and I will either link to here on this post or make a more complete resource guide. Of course this my annual PLEASE support this blog drive so IF you don't have these, get'm here.

In classic top ten countdown style I will start with #10 and work my way up to #1. Given the length of this post I have decided to split it into three parts. So without further ado here's #10

#10 - Linux(R) Quick Fix Notebook (Bruce Perens Open Source) - Prentice Hall Publishing tapped Bruce Perens, noted Linux guru for a series of books. The great thing about this book is that contains nearly everything you will want to set up but don't do often enough. Let's be frank here. Setting up and troubleshoot file servers, mail servers and web servers are not fun and unless you do it every day, you are likely to forget some crucial step to secure the web server etc. It's full of handy useful tips for things that you don't do often enough to remember but when you do them, it's a very good idea to do them well. Let's face it - you are a programmer and don't always have in long term memory the best configuration for a web server.

#9 - Linux Cookbook. Yet another O' Reilly's book that underpromises and over delivers. Helpful if you are just running a data center or just a single webserver. The cookbook format delivers very precise instructions with great writing. The humor delivered with this book makes this enjoyable and highly useful.

#8 - The Art of Project Mangement - If you are an open source programmer, you will at some point do project management. It cannot be avoided especially in the beginning of the project or when there are just a few developers. You can do this well or you can do what everyone else often does and wing it. For the project it's much more helpful to do this well. I look at project management this way. Remember the wagon wheel with spokes radiating from a central hub? Project management is that hub and without it the whole thing rattles and will certainly not work. Scott Berkun's book is well written, engaging and far from the typical dry project management book. Berkun is a former Microsoft employee He worked at Microsoft from 1994-2003, on Internet Explorer 1.0 thru 5.0, Windows and MSN. Say what you want about MS, those were the true heydays of MS development.

Thus ends part 1 of my three parter on 10 must have programming books.

Related Posts:
Part One: "Ten books an open source programmer needs to have on the shelf."
Part Two: "Ten books an open source programmer needs to have on the shelf."
Part Three: "Ten books an open source programmer needs to have on the shelf."

Writer's Block, TV, Tidbits, Nightstalker staked!

To be completely honest I have been suffering from a horrific case of writer's block. So I am taking the oldest remedy for it - Just writing untill the post takes a direction. There are several things I know I am definitely going to cover. You can see them up in the title there.

First off the last thing in the list - the cancellation of the ABC series The Nightstalker. The fans of the show of course were pretty rabid about it. I wasn't. For example Spotnitz's cancellation post on his blog is his notice and a few comments lamenting the demise of the show. - Not a single online site devoted to saving the site. It's not entirely surprising. I watched 1 episode boy was the formula off on the show. The Kolchak formula formula is different from the X-Files formula. Instead they adapted a version of CSI group of characters. This introduction of Team Kolchak was a mistake but it reflected Spotnitz's late X Files experience with john Dogget, Monica Reyes, and Dana Sculley.

I found the plotting solid on Nightstalker and the writing also strong. Stuart Townsend's performance was reserved but I suspect that was quite intentional. His character development was to have taken several seasons for the looks of it. I thought worked with Kolchak was that he wasn't a true believer ala Fox Mulder. He was a reporter. He didn't have connection to the Unknown through the death of his wife. He knew about as much as the every day guy when he started the episode (although each episode is told after the fact but story unfolds chronologically). This means the viewer's enlightenment and encounter with the unknown occurrs at roughly the same time it occurs with Kolchak. Kolchak is more of an every man than a Fox Mulder (who I may need to remind you was an Oxford trained serial killer profiler). Mulder was steeped in the unknown and more than equipped to quickly puzzle out things. Kolchak often consulted a whole range experts, professors and scientists. His character archetype was distinctly different, funnier and older.

I had my doubts about the ensemble approach with the Kolchak it appears that my fears were well founded. There is a silver lining in all this - You can now get the original series on DVD. For years fans have requested them on DVD, yet Universal couldn't be bothered to issue them. The new series made them get off their butts and actually release them on DVD. You can buy Kolchak - The Night Stalker here and Amazon will ship them to your door.