Recently, I had the opportunity to build a plugin with two other developers - Pippin Williamson and Andrew Norcross. We came up with the idea via Twitter, scoped it via email, and built it using GitHub using its tools all prior to releasing it.

I know - the title of this post sounds all too familiar especially given the global economy in which we all live today. After all, many of us work from our home offices, coffee shops, or wherever else while the home base of our company is located elsewhere.

But this is a different type of distributed team.

First, let's acknowledge that when it comes to building software in the WordPress space, we're extremely fortunate to be able to do so by ourselves, with a couple of friends, or within the context of a team in a corporate environment.

Even though WordPress itself is built by a lot of people all over the world, you don't often see the same experience being pulled through with themes or plugins. This isn't to say that it's never done (because it is), but it appears that it's done less so.

Now, the purpose of this post is not to promote the aforementioned plugin, but it's more of a call to action for us to find more creative ways to build publishing products with teams - namely, our "Internet friends" or tweeps - with whom we may not have previously worked.

But there are a few learnings that have come from this process that I think are worth sharing for the sake of helping others get into experimenting with developing projects with fellow tweeps.

Scope Is Key

Simply put, locking in the scope is part of identifying the core features of your plugin. When you first start out, it's important to be able to succinctly state what your product is going to do.

In our case, we said:

We want to make it easy for people to identify what comments need a reply from the post's author.

What this does is allow you to define a grid - or a scope - through which all potential features can be filtered. If it doesn't fit in with the core idea of the plugin, then it's not fit for the first release.

That said, this feels almost like it's a bit cliche because it should be expected for any software project: identify the scope, lock it in, and then aim for it.

But when you're working with a group of friends on a free project, this can become increasingly easy to ignore.

Case in point: As a single developer, how often have you thought to yourself: "That'd be a cool feature to build!" And then, because you had no one to really hold you accountable to build it, you were able to achieve it.

This isn't to say that's wrong - it may be, it may not be - I don't know the specifics of your project; however, if you're working with a team on a project, taking time to work on something that is outside of the scope is time wasted that can ultimately detract from the core of the plugin. Furthermore, it can hold up your peers' development time while they wait for your feature to be complete especially if there's a dependency on your work.

Finally, if you get a group of developers together to build something for the fun of it, the project may never get done because you've taken the idea of "wouldn't this be cool," and multiplied it by however many are on your team.

The point is that even though you're running the project with friends, you've got to scope the project lean, and scope the project early; otherwise, you'll never be done.

Delivery Date Matters

And this brings us to the second point: Despite the fact that you have no one "above you" holding you accountable to your delivery date, you still have an obligation to yourselves, your scope, and those who may be waiting for the product to complete development.

Granted, there's always the argument that can be made that since people aren't paying, then they have no real demand on when something should be finished; however, if you've set a date, there's a level of integrity that should be matched when aiming to deliver your work.

https://twitter.com/pippinsplugins/status/301792120266690561

To that end, it's important that you set a delivery date - however arbitrary it may be - and then set milestones to make sure the pace of development matches that date.

For example, Pippin, Andrew, and I scoped the plugin in February and aimed to have the plugin completed in April by the end of one of the WordCamp events. Sure, the deadline was somewhat arbitrary, but it kept us honest not only in our own development efforts, but it allowed us to hold one another accountable for our own specific tasks.

This means that if I was dragging my feet, Pippin or Andrew could call me on it (of course, it works all around).

Keep It Open

Finally, working with friends is great especially when you're unified around the same vision. It allows you to get more done faster since the work can be spread across more than a single person.

But the nice thing about software is that it can be open sourced. This means that if others are not only interested in the project, or are bought into the vision, they can even contribute to it.

But here's the thing, software is inevitably going to breed two things:

1. Bugs
2. Feature Requests

Using tools such as GitHub allows the plugin's user base - be it users, developers, or designers - to voice their issues and/or feature requests in a centralized way.

Furthermore, it allows the core team to not only assign each set of issues to their own milestones, but it allows for other contributors who are also brought into the vision know exactly how they can contribute. There's no guesswork. There's no "hey, maybe we could do this!"

Instead, there's a list of issues and requests that are needed (permitting the list is kept up to date) so that contributors know they are ultimately improving the product - not just blindly adding something because they think it would look good.

Of course, this isn't limited to GitHub: Whatever source control system and ticket system you opt to use, make sure it's something that makes it easy for others to interact and others to view outstanding issues. The last thing contributors need is yet-another-hurdle for contributing to your project.

Conclusion

So there you have it: Three points to working on products with a distributed team outside of the typical organized environment.

Simply put, make sure that you scope your project, stick to your delivery date, and allow others to contribute who are interested. By doing this, you're making it easy not only for your current team, but your future contributors to improve the product.

Finally, I've avoided discussing the plugin that Pippin, Andrew, and I built specifically because I wanted this post to be about the process, not the product; however, now that we've covered the former, you can find the latter here on GitHub. If you're interested, feel free to leave us issues, notes, or even pull requests!