Three Lessons From Open Source (Or “Working on The WordPress Plugin Boilerplate”)

As I’m getting ready to tag and release version 2.6.0 of the WordPress Plugin Boilerplate, I’ve been thinking about the some of the lesson from open source that I’ve learned over the time of managing the project

So, I’ll be the first to admit that the boilerplate is by no means a large project; however, it’s the first project that I’ve had that’s received a number of contributions from people who have made the project better, who have taken part in good discussion around how things should be organized, and who are extremely forward thinking as it relates to future functionality.

What went from a couple of commits from myself over a couple of months and turned into:

  • 236 commits
  • 2 branches
  • 9 releases
  • 26 contributors

It’s not large by any means, but it’s definitely fun to see something that went from a couple of commits from myself to something in which a number of others have gotten involved.

Three Lessons From Open Source

Again, I still consider this a very small open source project, but as someone who has contributed to significantly larger projects, I can understand how challenging it must be to manage an major open source project.

In the short time that I’ve managed the boilerplate, here are three lessons that I’ve learned:

1. Milestones Matter

The First MilestoneWhenever I begin a new project either for myself or for a client, I always take the requirements and scope of the project and break it up into milestones.

Not only does this help with really getting a hold of building something large, but it helps to set expectations of what features will and will not be included in the current milestone, and what’s planned for future development.

Up until this latest release, I haven’t done this with the boilerplate and I’ve regretted it.

It results in releases that have a set of changes that aren’t really related or planned – it’s simply a arbitrary statement of “okay, I’m going to release this today.” And then you go with it.

This does nothing for managing expectations, future requests, and versioning.

2. Pick a Versioning Scheme

Personally, I’m a fan of semantic versioning (though I also like the simplicity of larger release numbers that we’re seeing browsers do these days) and I’ve opted to begin releasing the boilerplate following this particular scheme.

To my own detriment, I’ve been inconsistent such that I’ve been saying that the next release will be 2.8.0 when, in fact, it’s really going to follow the previous release of 2.5.1 and be 2.6.0 (with a milestone already planned for 2.7.0).

When it comes down to it, my own reasoning for this is poor and I simply hit a point where I realized that I needed to pick one of the more popular schemes and go with it.

Not only does it make it easier to tag code and plan milestones, but it also goes back to setting expectations – if you’re running 2.5.0 and you notice that 2.5.1 has been released, then it means a bug fix has been released.

3. Listen To Your Contributors

What starts off as a pet project may ultimately grow to be something that various people are working on with you. That’s but one awesome aspect of open source.

Though you may still consider yourself a lead on the project and decide what gets pulled in, what gets punted to other milestones, what gets rejected, and what gets discussed, you still should listen to the people who are offering contributions and discussion to your project.

They aren’t trying to take your pet project away from you: they are trying to make it better and they are doing so using their most valuable resource – that is, their time – with no expectation of payment other than perhaps their name in the ChangeLog.

You Don't Say

On top of that, you’re going to interact with people who are more experienced and smarter than you. Be thankful – not frustrated – with that.

You’re getting your code reviewed by people who have been doing this longer and who are more familiar with standards, you’re getting code submitted that’s cleaner, and potentially carries a lighter footprint, and you’re receiving this all simply because people like something that you’ve started.

You will become a better developer and a better person if you take time to listen, learn, respect, and implement some of the things your contributors offer.

That’s All?

Hardly. This list could go on for quite a while so perhaps I’ll write a follow-up later on, but the short of it is that open source projects should not only welcome a community of developers around the project, but should also provide a way in which you can better yourself as a project manager, developer, and even contributor.

On top of that, I can’t help but gain respect for those who have run projects on a significantly larger scale. It’s clearly a massive undertaking in which you’re have to manage a lot of moving parts.

But for now, the WordPress Plugin Boilerplate is nearing it’s 2.6.0 release (with all closed issues and a few items to review prior to launch).

2 Replies to “Three Lessons From Open Source (Or “Working on The WordPress Plugin Boilerplate”)”

  1. “On top of that, you’re going to interact with people who are more experienced and smarter than you. Be thankful – not frustrated – with that.”

    Agree completely on this point! I’ve added some really good patches and features to my plugins because of contribution from various users. Many of which I am sure I wouldn’t have been able to code in myself!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.