The Apostrophe project has been around in some capacity since the early days of P’unk Ave. It’s an open source content management system that we use to build almost all of our client projects. Version 2– a complete rewrite using a totally different technology stack– has been around for a year now. It’s a massive project with a lot of moving parts and, while it has been a great success so far, I’d be lying if I said the last year of Apostrophe development was all sunshine and rainbows.
I’d like to share some of the difficulties we’ve experienced in managing an open source project on top of our client workload and how we’re making it work today.
We hear a lot of talk in the development world about “silos”. When someone on your team has a particularly advanced set of skills, or perhaps works at an unreasonably fast pace, they end up being the decision-maker and knowledge-holder for a disproportionate amount of the work. We happen to have a brilliant engineer in our midst who could program you under the table without breaking a sweat; he’s the reason Apostrophe exists, and yes, he can be a silo at P’unk.
He has a tremendous ability to power through any programming problem and emerge victorious, so it’s only natural that Apostrophe 2 came into existence through a short and stunning burst of energy last year. It’s great from the perspective of P’unk Ave; we were able to build a new version of our CMS within the context of a single client project. The flip side? Ownership. Not in the who-has-the-copyright sense, but in the sense that not everyone felt an equal stake in the project. It’s only natural. The decisions that had to be made in that burst of development couldn't have all gone out to a vote or it never would have happened.
In response to this, the general feeling was “darn”. Darn, why does it have to be this particular way? Why this file structure? Why those function names and not these? It’s a natural reaction, but it wasn’t communicated right away. That “darn” feeling lingered for a while and eventually turned into… “damn”. Damn is bad. Damn is “I don’t like this anymore”. It’s a destructive place to be as a team.
The thing that really turned us around was communicating effectively. Specifically, communicating our excitement. Being negative is easy stuff and in the long run it’s not constructive; sharing those “what if!” ideas is infectious. What if the file structure was this? What if the function name was that? How nice would that be? Excitement is the element that opens up someone’s schedule and creates an extra hour in the day.
Excitement is the currency of open source software. It takes a fair bit of enthusiasm to sit on your couch at 8pm and sift through GitHub issues, but for some reason we do it. What we weren’t doing before was seeking it out: looking for opportunities to get excited.
Another lesson we learned was in pausing deliberately for the sake of ownership. There are plenty of situations where someone is working on a problem and they know, beyond a reasonable doubt, what the right solution is. Instead of acting on it right then and there they pause, gather up a handful of team members, and say “what should we do?” We all agree on the solution together, and now we’ve all felt good about it. It doesn't have to be a long, drawn-out process. Grabbing three people for a five-minute conversation can pay an amazing dividend.
There’s something powerful about posing a problem to your team and watching someone light up thinking about how they’d like to tackle it. It’s an unstoppable force. Knowing they will learn something from it, own it, become an expert on it: these are the things that resonate with us as a company. Over the last few months I’ve seen our Apostrophe todo list split up more and more equally among our team members, to the point where the code is starting to feel like a magical mix of all of our skills.
We’re finally using all this energy to write proper documentation. In the spirit of team ownership we are all going to write a piece of it. As that comes together we’ll be moving through some new feature development and pretty soon we’re going to find ourselves talking about the project as equally motivated champions of its future. I believe these lessons are giving us the perspective we need to get other developers involved and share our work and vision among the larger open source community. That's exciting.
