When I threw the WordPress Plugin Boilerplate up on GitHub a couple of years ago, it was merely meant to be a place for me to share how I [used to] start off most of my plugin-specific projects.
Sure, it’s changed over time (as things do as we gain more experience), but it’s also grown into something that’s received a number of contributions both of which are around ideas for what should or shouldn’t go into the plugin, as well as a variety of pull requests to solve issues – some defined, some not – all from very generous people.
What started off as a small personal project, has grown into a project – although that I still consider small – has a significant enough level of interest and activity that I’ve had to introduce a little bit of project management into maintaining it.
This was obviously something I never set out to do, but it’s something that’s become necessary. So with that said, I thought I’d do a short series on what I’ve learned about open source project management.
Over the next few posts, I’ll cover an idea or two that I’ve learned – at least thus far – that I believe to be cornerstones in open source project management.
Open Source Project Management: Vision and Mission
I’ll be the first to admit that there are some significantly large open source projects that have changed my – and others – life.
Off the cuff, this includes Unix, Linux, WordPress, and more. I’m not claiming that I’m comparing the Boilerplate is even remotely on scale with those projects.
That’s arrogant and highly misguided.
Instead, I’m simply sharing what I’ve found useful within the context of a small open source project in an attempt to document my own experience, and to perhaps help anyone else who stumbles across this article.
Vision and Mission
From the outset of the project, I wanted to have a very clear mission and vision for the Boilerplate (truth be told, I try to do this with every personal project on which I work).
First and foremost, vision and mission are not the same. There are different definitions for each, but my favorite definition is as follows:
Vision is a clear mental picture of what could be, fueled by the conviction that it should be.
This can be for a product, service, an organization, or what have you. As it relates to software, this is typically relegated to products (or products as services).
A mission statement, on the other hand, asks:
“Why does this [product|service|company] exist?” It should be short, concise and easy to memorize. It should inspire you, and many others, to invest time and talents to accomplish it. It should be used as a tool with which your team makes decisions.
Now, don’t get me wrong, this doesn’t mean that I sit down and take notes for each project and memorize it. Instead, I think of it as a short, simple explanation of what the product does, the solution it solves, and why I think it matters.
For example: The vision of the WordPress Plugin Boilerplate is to provide the strongest foundation possible off of which developers can write WordPress plugins.
The mission of the project is to aid developers in following WordPress best practices, coding conventions, and file structure so as to make efficient, easy-to-scale and easy-to-maintain plugins.
Whether or not these are explicitly stated – which, for more formal projects, I think ought to be – should be understood by all parties involved. It provides a filter through which you know how to evaluate incoming ideas, future features, deprecating older features, and more.
Should The Mission and Vision Change?
I don’t want to say “never,” because, honestly, you never know, right? There are potential variables that we simply can’t see from the vantage point that we currently have.
With that said, I lean in the direction of saying if they change, it shouldn’t be a hard 90 degree turn. It should be something that’s just flexible enough to adapt to the context in which the software is running.
So, because the nature of software is that it changes over time (as does the foundations on which it is built), the vision and the mission – if considered correctly – should be able to stay the same.
For example, if some new coding convention or best practice arises, then the Boilerplate would need to adapt to that. What once was the norm now becomes deprecated, and makes way for something new.
But the above statements about the project, namely:
- The vision of the WordPress Plugin Boilerplate is to provide the strongest foundation possible off of which developers can write WordPress plugins.
- The mission of the project is to aid developers in following WordPress best practices, coding conventions, and file structure so as to make efficient, easy-to-scale and easy-to-maintain plugins.
…should remain true. It’s just that the way they are accomplished may change.
This Isn’t Fixed Per Project
Finally, this will naturally vary from project to project. Whatever is the vision and mission for one project isn’t – and probably shouldn’t – be the same for another project. I’m simply using one project to define an overarching point.
Perhaps it’ll be worth revisiting this once another project is released, but that’s for another post.