This is the fifth and final part in a series on What I've Learned About Open Source Project Management.

Though some may argue, I think that all projects – open source or not – ultimately culminate in releases. That is to say that when it comes to building software, your ultimate goal is to provide a solution for your users that gracefully solves their problem.

I think all developers strive for kaizen in their work, but because of our own nature, we end up shipping things that sometimes feel like a step back, sometimes introduce more bugs, or sometimes simply dissatisfy the user.

Of course, that’s only one side of the story, right?

On the other hand, companies and developers do often ship incremental improvements of their software much to the delight of their users. And though that’s not always the case, it’s something for which we all should aim.

Everything that’s been covered in this series leads up and contributes to releases.

How this works in closed source software may or may not be the same as it works within the confines of open source project management – I’d venture to say that there’s overlap – but nonetheless, here are my takeaways with respect to aiming for releases in open source project.

Open Source Project Management: Releases

First, I think it’s important to understand that releases often have to do with two things:

  1. How the project is managed,
  2. A global view of the vision and mission of the project.

To me, those two things are key in defining releases and making sure they ship at whatever date you’ve specified.

But what does this mean, really?

Bottom line: It means that the person – or people – at the helm of the project are not only keyed into the vision and mission of the project, but are able to see what issues and pull requests should be created in order to further improve the core product.

Furthermore, they are able to see how one issue may be the foundation for another and can prioritize work accordingly. This may mean that any given issue, feature, or pull request is delayed by a release or two or even more; however, that’s all part of managing the project, and part of being able to steer project toward that goal.

What Are Releases?

As with the rest of the topics in this particular series, I think that it’s important to provide a working definition of exactly what a release is so that we’re all on the same page as it relates to the discussion:

A release is completed milestone; it is a collection of resolved issues and new features that enhance the previous version of the project.

Simple enough, right?

I think that there are a number of ways to define it, but given that we’ve talked abut milestones, issues, features, and pull requests, I think that this summarizes it succinctly and within context.

When Are They Ready?

This is always a tough answer to provide, because it largely depends on the schedule that you’ve set for the project.

  • If the deadline is self-imposed, then the project will likely be released on a given deadline with or without the initial set of issues completed. If they aren’t completed, either the release date will be moved, or outstanding issues will be moved to the next milestone.
  • If the deadline is nothing more than “when the given milestone is complete,” then that’s when the project will ship. This isn’t to say that contributors shouldn’t take their time in working on the project. It’s just to say that others can monitor the work of the project, and then expect a release when all of the outstanding issues for the milestone have been resolved.

Are there other ways to determine when a project should ship? Sure – but again, all of the posts in this series are being written from my experience with the WordPress Plugin Boilerplate.

Some releases have come right on the heels of others; other releases have come months after the other.

want to say that I like the quick releases more, but the truth is that I’m just as proud as the short, quick releases as I am of the ones that have taken longer because each one has been carefully completed with creating the most robust solution possible given the set of issues and the time delegated to reaching the milestone.

How Many Should You Plan?

For some reason, this is a question that pops up more frequently than I’d expect within software development.

To me, it seems as if the goal of software is to give your project life. That is to say that you give your project a roadmap that will extend to some undetermined point in the future so that you’re not only able to continue solving problems for others, but that you’re also able to continue working on the project and thus generating revenue.

Don’t misunderstand me: The primary point of giving your software a roadmap is not to generate revenue, but to solve problems for customers and users that will in turn generate revenue.

It’s a byproduct of a successful project.

To that end, I’ve rarely worked on a project in my professional career where someone said “we’re doing two releases and then we’re done.”

Instead, it’s always been about shipping the first version and improving upon that, and fixing any issues that crop up along the way all the while continuing to improve the core product.

So if you’re going to ask me “how many releases should I plan?” I will always respond with “I don’t know, and hopefully you don’t either.” Instead, just aim for releasing the current milestone, and working on the next one from there.

And that’s what everything that has been discussed contributes to:

  • The vision and mission keep us on track for the problem(s) our software ought to be or should be solving
  • The milestones are the markers by which we measure the completion of our issues
  • Issues can be solved by pull requests or patches by contributors or by yourself
  • Each completed milestone should result in a release

And then you rinse and repeat from there.