Open source projects are very difficult to lead, because there are so many people that participate, with so many conflicting goals. Add to that: If your project is used by a business, especially if the business makes money doing something related to your project, even if you are unaffiliated with that business, you can expect regular and constant flame wars erupting. (I might add that normally the people who are most opposed to commercial involvement, and a “business stealing from the project” are people who have contributed absolutely nothing, and thus personally have nothing to be “stolen”). So this results in substantial amounts of our resource time going to fighting fires instead of working on the project.

The last big thing that makes releasing a “stable” release on an open source project is that it’s very hard to make a release good enough to go out the door. This particular issue is IMHO one of the strengths of the project. As an engineer it’s very hard to predict what will be important to your users. If you have constant feedback from your community, you can see how things break for others, and it means what you release in the end is far better.

All in all, I have learned a ton in the last year about how to have a leadership role in an open source project, which I’m gonna need this coming year, as the changes we are implementing in pcgen over the next calendar year are going to be very deep, structural and profound for the project. Hopefully the experiences of the last year has taught me and the rest of the team a lot.