Developing Plugins With a Distributed Team


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.

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

GitHub Repository

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.


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!

Related Posts
  • Code
    Tools & Tips
    Coding in the CloudCoding in cloud retina preview
    The Internet has allowed us to work anywhere we want, giving us tremendous flexibility in choosing where we'd like to plant ourselves to build the next great app. Not being tied to an office desk has been a blessing to many who cherish the ability to work in varying environments and draw inspiration from their surroundings. But for the most part, we've needed to have a full-blown development machine to make this happen. What if we could leverage the cloud as a development environment itself, freeing us up to choose from a variety of devices to accomplish the same thing. That's what we'll explore in this article.Read More…
  • Code
    Easy Ways to Contribute to Open-source ProjectsOpen source retina preview
    When the jQuery project first started, I remember how passionate the team was about helping developers use the jQuery JavaScript library. It was a labor of love with all of us putting in countless numbers of hours, day and night, to help grow the project and the developer community. And we did those for free because we just loved doing it. But as the project grew, so did the expectations from the community in terms of features and support. And this is where most open-source efforts fail to scale. Read More…
  • Game Development
    How to Learn
    How to Learn the Phaser HTML5 Game EnginePhaserlogo400px
    Phaser is an open source HTML5 game framework created by Photon Storm. It's designed to create games that will run on desktop and mobile web browsers. A lot of focus was given to performance inside of mobile web browsers, a growing and important area of web gaming.Read More…
  • Code
    Interview With Eric Bowman of Gilt.comEric bowman retina preview
    While most of us have built really cool websites, realistically speaking, few developers have had to worry about the complexities of managing and scaling incredibly large websites. One thing is putting up a site for a small company to ensure they have a great presence and another is trying to figure out how to scale your site so it won't buckle under the load of thousands of users. I was fortunate enough to chat with the folks a flash-sale site which has received quite a bit of press over the years and seen tremendous growth. It's opportunities like these that allow us to probe the team that manages these sites and learn how they handle their day-to-day business and technology. In this interview, Eric Bowman, VP Architecture at Gilt Groupe takes us through some of the background behind the site and the technology decisions behind keeping the service running smoothly.Read More…
  • Code
    Tools & Tips
    How to Collaborate On GitHubGithub collab retina preview
    If you don't already know, GitHub is an incredibly effective way to collaborate on development projects. Providing a place for anyone with an internet connection to have an avenue where they can share code with the world for free (not to mention the robust supporting tools for source inspection and easy viewing of commit histories). GitHub has been adopted by many large open-source projects as their primary home for collaboration and contribution. But how do you join in and contribute to a project? Sure, you know how to use Git to track changes to files and push those files to a server. But there are major benefits to getting involved in larger open-source projects, and GitHub is arguably the best place to start. Today, we will discuss a few rules of the road for collaborating on open source projects, and give you the knowledge and intuition you will need to get involved.Read More…
  • Web Design
    Case Studies
    How They Did It: The Accessibility ProjectA11 preview
    Perhaps you, or someone you know, has experienced the difficulties of computer interaction for the impaired. In general, operating systems and software suites have made provisions for accessibility for hearing-impaired audience, vision-impaired audience, and internationalization; however, the open web hasn't caught up as quickly. Many sites ignore accessibility completely.Read More…