How did you get started with development, and when did WordPress come into the picture?

Like a lot of developers I’m completely self taught. Most of my childhood was spent without access to a computer, when we did finally get one around age 14 I dove in headfirst and quickly found building things was something I really enjoyed. The first real website I built was for my father’s Stone Masonry business. (It’s still online if you want a giggle —
http://derbyshirefireplaces.co.uk
. I’m particularly proud of the “This Web site is best viewed with Mozilla Firefox and a resolution of 1024×768 or above.”)

I spent the next few years mainly focused on front-end development; not being very good at design I got really into the web standards movement and spent a lot of time in the CSS Beauty forums having arguments with people about whether it was ok to use Dreamweaver for development. I discovered WordPress around 2005 (version 1.2 – 1.5) and spent the next year or so doing it on the side as a bit of a hobby (I had a day job at this point). At the beginning of 2007 that all changed, I quit my day job and decided to go full time as a freelance WordPress developer. Looking back now makes me realize what a risky decision that was considering how little I actually knew about the industry or the craft.

I spent a few months building pretty bad websites for small companies, some with WordPress, others just static, then late in 2007 my luck changed and I literally fluked my way into a full time contract position doing WordPress development for a large US company. At this point I wasn’t really even sure what a function was. I won’t bore you with the details but in WordPress terms I started the contract as a boy and left it as a man, with experience leading the development of large WordPress powered sites. I’m proud of the things we built there — they were somewhat ahead of their time (come find me in the bar after a WordCamp if you want to hear me wax on about it).

Tell us about how Human Made and how that came into being.

At the same time that I was contracting as a WordPress developer my younger brother Joe Hoyle was also becoming interesting in web development. We started working on projects together and after a couple of years doing this it just got to the point where it made sense to start a company. This was back in early 2010 and we’d just finished working with Aardman Animations, someone we were proud to be bringing over to WordPress. We incorporated Human Made Limited on April 29th 2010.

From the beginning our aim with Human Made was to do great WordPress work. As we’re both developers we’ve always focused on the quality of our work as a differentiator rather than our sales skills; when we were freelancing, work generally found us and since becoming a company this hasn’t changed.

How has the business changed over time?

Human Made has changed fairly significantly in three ways over the past few years. Firstly, we’ve grown. We’ve grown the number of people who are part of the company from two (my brother Joe Hoyle and I) to 10+ (as of this writing). We’ve grown in terms of the level of work we produce — from staying up all night trying to figure out how to get Gallery2 integrated with WordPress, to producing sites for some of the world’s most recognizable companies as a WordPress.com VIP partner. We’ve also grown in our ambitions, from wanting to build a company that could let us do what we loved (making things with WordPress) to wanting to create a company that can compete with the best.

Another big change the business has undergone has been a move from building things purely for other people, to also building things for ourselves. This started with WP Remote, which slowly turned into a fairly popular service and served to whet our appetite for the challenge of building and marketing our own products. We now have a couple of products under our belt with even more planned.

The final big change we’ve undergone has seen us becoming an active part of the WordPress community. We attended our first WordCamp in 2011. That was a catalyst and since then we’ve attended, sponsored and got drunk at every WordCamp we could get to. I was also greatly honoured to be invited to attend the inaugural community summit in 2012. I wish we’d got involved sooner.

You’ve worked with some illustrious clients. What do you think has been most important in winning their respect and ultimately contracts?

Respect is something that is won over time — you rarely start a project with the total respect of a client, especially when most clients have likely had bad experiences with other agencies / freelancers in the past (as ours often have). We win the respect of our clients by being honest and always trying to do the best work we can — good clients respect that. We’re proud of the fact that our clients tend to stick with us over the long term, sometimes for years, it’s a good sign that we’re getting things right.

When it comes to winning new work, the biggest single determining factor which we’ve found has been our existing client / project list. Our sales strategy (if we have one) is to make it obvious to the client that we would be the best choice. If the client sees we’ve worked on similar projects for similar clients in the past and that those previous clients are still with us, gave us a good testimonial, or even better, are happy to chat to the new client and sing our praises, then that’s much better than us just going on about how good we are.

What would you have done differently if you were starting out now, in 2013?

I would have got into the community straight away. When I first started out I was fairly unaware of the WordPress community and even when I did become aware, I was more of a watcher than a participant. In some ways this was a conscious choice and had some benefits; it meant that I didn’t get on the wrong side of any of the great debates / controversies that have swirled up at various times, debates on topics I wasn’t expert enough in to make a positive contribution. The downside is that I missed out on meeting a lot of great people and probably took a bit longer than I might have to learn my craft and discover the parts of it which interested me the most.

Of all of the projects you’ve tackled, which are your proudest of and why?

That’s actually a really difficult question, as clichéd as it might sound, I’m proud of a lot of different projects for different reasons. Sometimes it’s the complexity of the work that I’m proud of, sometimes the quality of what we’ve been able to deliver, other times I’m proud of how we’ve worked around things like budget or time constraints. If we don’t have something to be proud of in each project we do, then I’d see that as a failure.

If pushed I’d probably say that I’m most proud of our free web app WP Remote. It’s hard not to feel proud when you see people using something you’ve built, even if it makes us no money! Some of my proudest moments are meeting people at WordCamps and hearing that they use and love WP Remote.

You’ve built a strong team over time. What do you typically look for when you’re bringing in a freelancer or new team member, and what sets them apart from the competition?

Hiring great people is hard and I still have a lot to learn, however I do think we’re lucky in that we have WordPress community which makes identifying great people a hell of a lot easier. There are several traits which I look for when hiring that are also often shared with the kinds of people who get involved in open source, be it in code or the community. There’s no need to have rounds of boring and ineffectual technical interviews if the person you’re hiring contributes to open source, you can already see their code!

We currently see ourselves as a distributed company which just happens to have an office. At the moment all our growth is going to be distributed and that also opens up our options a lot. Ultimately we try to hire people who care about the quality of what they are putting out into the world, people who have a passion for what they do and who want to get better, no matter how good they already are.

How important, if at all, has the WordPress community been in your work and business?

My first few years working as a WordPress developer were spent outside of the WordPress community. I was completely unaware of its importance back then, although I’m sure the reason I had enough work was because of all the great evangelism the people participating in the community were doing — thanks guys!

These days the WordPress community is important to both my work and our business in a countless number of ways. It supports nearly everything we do and is hard to narrow down to a sound-bite or list. Being part of something as large, vibrant, and downright incredible as the WordPress community feeds my passion, it’s a daily inspiration and a constant reminder to aim higher.

It’s also important in several practical ways, for one, it’s much easier to hire people when they all go to the same conferences as you and take the time to get up on stage and prove their expertise. The community fosters a sense of belonging that would be impossible to reproduce as a company on our own, leaving our developers exciting and proud of what they do.

Being part of the WordPress community lead us to meeting Noel and building happytables. It’s also how we first met several of the developers who now work with us.

Tell us about happytables, and the problem you’re trying to solve there. How is serving the means of many users different to serving the needs of a single client?

The problems we are trying to solve with happytables are pretty simple, however that doesn’t mean we take it easy when solving them! It just means we get to focus on solving them really, really well. The obvious core problem, and the catalyst that brought happytables into being, is that most restaurant websites are really, really bad. Happytables co-founder Noel Tock details some of ways in which they suck on a cute website he runs at
http://better-restaurant-websites.com
.

The cause of all these bad restaurant websites is also fairly simple — most restaurant owners aren’t web designers so they struggle to build themselves great websites. Neither do most have a huge budget they can spend hiring a great web designer and finally, most of the services that purport to allow people to create a website for their business are usually rather generic and often aren’t very good themselves.

With happytables we solve all three of those problems. By building a solution aimed specifically at the needs of restaurants we can focus on giving them the features they really need without any cruft. This has the added benefit of making it really easy to use — most restaurant owners get a site up and running in under an hour. Because it’s a hosted solution we can operate at a scale which means the cost stays low for individual restaurant owners but we can still deliver them a really high level of value.

In some ways it isn’t that different from serving the needs of a single client, I’m a big believer of building sites for the users and the client is rarely the user of the site they’ve hired you to build. Just like with a single client build it’s important to focus on the vision you have for the project and say no to features that don’t fit within that.

If you could pinpoint three of the most important things that have made a difference to your business since you set out, what would they be?

1. Co-founding. You gain far more than you lose if you find the right partner.
2. Being focused. There are so many opportunities out there and it’s so tempting to try to do everything. Be that offering every possible service instead of the just the one or two that you’re actually good at or building product after product without ever really finishing any of them. If you want to aim high then you have to focus.
3. Products. We love working with clients, but building our own products is another level of experience entirely. The chance to refine over the long term, to experiment, to be truly creative within the constraints as you see them; it’s wonderful. Try it.

How did you first get into web development, and at what point did WordPress enter the picture?

I first got into web development in 2001 when I was working for the Labour Party — I was asked to join the editing team for their general election site and I took the opportunity to learn some HTML while I was at it. A while after this I designed websites for learners when working in management development, which prompted me to consider going into web design and development full time. I set myself up as a sole trader in February 2010 and formed my company, Compass Design, in September of that year. By then I was starting to develop more and more sites in WordPress for clients who wanted to be able to update and manage their own site. By 2011, I was working exclusively with WordPress.

As the head of Compass Design, you’ve chosen to specialize in mobile and responsive WordPress design. Where did the idea come from to focus on this area specifically, and has specializing helped set Compass Design apart from the pack in terms of positioning and winning clients?

To be honest I can’t really remember! I know I had a client in 2010 who wanted a mobile version of their site — this was before responsive design had taken off, so we used a plugin. After that I started taking an interest in mobile design and development because I was increasingly using my own phone to access the internet. I gave my first talk on the topic at WordCampUK in July 2011 after which it seemed to make sense to develop this area and focus on building responsive sites for clients. I was lucky that this new technique was emerging as my business was growing, as everyone was in the same boat and the more established agencies didn’t have any more experience in responsive design than I did — in fact, not having years of doing things another way gave me a bit of an advantage in some ways.

I think it has given me a slight edge, as I’ve definitely picked up clients who’ve seen my writing and that gives them confidence in my ability before they even speak to me. But as with any business, what wins me clients (exclusively referrals, these days) is providing a great service and taking time to understand what my clients’ real needs are.

How do you typically convince would-be clients that they need to bring their site into the mobile age, and do you ever encounter any resistance to the idea?

It helps that I don’t charge extra for making a site responsive, I see it as part of my offer, so it’s included. I find that if I ask a client to hand me their phone and point the browser at a responsive site I’ve developed, that convinces them pretty fast. Many clients don’t think they need a responsive site until they see it, and if they’re ambivalent at first, when they hold their own site in their hand, there’s always a ‘wow’ moment. So I’ve been lucky not to encounter any resistance!

Where do you see designer-developers going wrong most often in their approach or implementation of responsive design, and what pitfalls should they be most mindful of avoiding?

I don’t think that there are examples of people ‘going wrong’ as such, but I do think that the way responsive design is approached is evolving and designers and developers need to keep up with that. For example, when we started writing media queries, they were always based on the iPhone’s dimensions, and after a while that expanded to accommodate iPads and other large tablets. But now there are so many devices of different sizes that the breakpoints for media queries should be set at the screen width where the design breaks, not at the width of one specific device.

However I do think there’s one area where designers of mobile-specific sites (as against responsive sites) get it wrong, and that’s when they don’t make all of the desktop content available to mobile users. Some big brands still make that mistake and it drives me nuts.

You’re the author of WordPress Mobile Development Beginner’s Guide, WordPress Theme Development Beginner’s Guide, the forthcoming WordPress: Pushing the Limits, and also have a novel on the back burner. What part has writing played in your life, and how has it dovetailed with the knowledge and experience you’ve built through your design-development work?

I’ve always loved writing. At school I loved writing stories and mini-novels and I’ve planned and started quite a few novels in my time; this is the first one I’ve actually finished, and someday I hope to see it published. In just about every job I’ve ever held, I’ve spent a lot of time writing, partly because colleagues have recognized that it’s something I do well. Now I’ve had two WordPress books published, another due out in June and have written articles for a variety of online journals. I’ve been incredibly lucky to be able to combine my work designing and developing websites with writing, and can only thank Packt for approaching me with the proposal for my mobile WordPress book which kicked it all off.

Tell us a bit more about your Mobile Development book, and who would benefit from reading it.

The book is aimed at people who’ve got some experience using WordPress to build websites, know their way around the admin and can maybe write a simple theme, but have little or no experience of mobile development. It takes them through the process of making a desktop site mobile-friendly, looking at plugins, media queries, and web apps, and has content that’s relevant for developers who don’t work in WordPress but want to learn about responsive design.

Are there any cases where a designer-developer shouldn’t be putting responsive design best practices to use in 2013?

There are some scenarios where a site’s users have very different needs on different platforms, in which case I would develop separate themes for mobile and desktop. But this should be based on mobile/desktop users having a defined need to complete different processes, not on the needs of the site owner to speed the site up, save money or avoid the complexities of making an existing site responsive. In 90% or more of cases, responsive design is the way to go, in my humble opinion!

Where would you point a reasonably new WordPress designer-developer looking to get up to speed with responsive and mobile friendly design, and are there any essential shortcuts, plugins, or other helping hands they should keep in mind?

The default WordPress theme, Twenty Twelve, is responsive, and picking that apart can help developers understand how a responsive theme works. However I think the basics of responsive design are independent of any CMS so I would encourage theme developers to read Responsive Web Design by Ethan Marcotte, which will show them how to write media queries and create a fluid layout. Another great but not so well-known book is Stunning CSS3 by Zoe Mickley Gillenwater, which I read before Ethan’s book and which taught me a lot about responsive design.

As far as essential plugins are concerned, the three I use the most are Responsive Select Menus, which turns navigation menus into select boxes, Mobble, which lets you send different content to different devices using conditional tags, and WP Responsive Images, a really clever plugin that automatically sends smaller image files to mobile devices without relying on user agent sniffing.

You’ve also presented on the case for creating WordPress-powered web apps. What makes WordPress a good basis for a web app, and are there any key tweaks or streamlining measures a designer-developer should keep in mind when adapting WordPress to web app scenarios?

The main reason I would recommend WordPress for web apps (or many other CMSes, for that matter), is the fact that you can use a separate theme for your web app while still having all of your content in one place in the database. This means that any overlapping content between the main site and the web app doesn’t need to be duplicated. It also makes it easy to let users switch to the ‘main’ site on mobile devices and see a responsive site as against a shrunken version of the desktop site. In addition to this, there are loads of WordPress plugins out there providing the kind of functionality web apps require: ecommerce, mapping, forms, events management, and much more.

How well does WordPress work out of the box as a mobile/multi-device platform, and are there any improvements you’d like to see in future versions to better solve the challenges that the mobile web presents?

WordPress is pretty good as a multi-device platform, given that it comes with a default theme that’s fully responsive. For the front end, I think the main area for improvement is around image management. While there are plugins that deliver smaller image files to mobile devices, I’d like to see WordPress’ media management integrate with the proposed new picture element to give finer control over the way images are used and displayed. This is a way off yet, and is reliant on the W3C developing the proposed element further.

For the admin system, I’d like to see it being easier to manage a WordPress site on an iPad. There’s a great WordPress app for smaller mobile devices, but on the iPad I tend to use the browser to interact with WordPress and there are some aspects of that that don’t play nicely. I know that the community of WordPress core developers are working on these though, which is great news.

Finally, you’ve recently written two books that focus on users at two polar extremes of familiarity with WordPress. What challenges were there in communicating about WordPress for beginners versus seasoned veterans looking to push the envelope of what’s possible with WordPress?

Working on these two books at the same time has been a real challenge. One day I’m writing guidance for novice WordPress developers to help them build their first theme, and the next I’m delving into PHP to find ways advanced users can push WordPress further for complex client projects. The first has been enjoyable because it allowed me to recap my own theme development skills and ensure they were up to date, while the second has been a great learning experience for me experimenting with aspects of WordPress and investigating techniques developers are using to push WordPress way beyond its original function as a blogging platform. This book, WordPress: Pushing the Limits, has been my greatest professional challenge to date (not least because of the tight writing deadlines) but also one of the most enjoyable things I’ve done and it’s inspired me to push further with the work I do for clients.

Quick Overview

As a designer-developer, you’re quite possibly up to your ears in plugins. So what if you could use, erm, yet more plugins to manage the aforementioned… plugins. Stay with me. WP Mayor has a handy introduction to a couple of useful plugins that will make managing plugins you use regularly from install to install, or trying out your favourite plugins on for size before unloosing them on your site visitors.

Image based on P Givens by HiMY SYeD, CC-BY-2.0.

How did you first get into using WordPress?

I started using WordPress in 2006 in the web 2.0 and blog boom when I was looking for a good learning resource for new web technologies. I tried a few CMSs, but decided on WordPress. I have been creating custom CMSs for my clients with PHP and MySQL since 2001, so using WordPress was comfortable from the beginning. Needless to say, WordPress is still the best resource for people to learn the latest web development techniques.

How did you get involved in the WordPress community?

My first contact with the WordPress community was submitting a bug fix to Core trac. I also created a .org account with the silly ID “tenpura” (I never imagined I would be so involved in the WordPress community in the future). Later, my bug fix was merged into the Core code and some people appreciated my work. This experience opened my eyes to open source community contributions and influenced the work I am doing now.

Tell us about how you contribute to the WordPress community.

In 2007, I worked with some peers to start ja.wordpress.org. Since then, I have been maintaining the site and ja packages, answering forum questions, and organizing WordCamps. As the local community grew, my contributions became eclectic. I’ve constantly contributed to core trac since I started using WordPress. The WP Multibyte Patch plugin might be my most unique contribution. It transforms WordPress into a perfect Japanese version of WordPress not only in language, but also in functionality. Some of the functionalities common to other languages have already been merged into Core. This was a discussion topic at the WordPress Community Summit 2012.

When did you set up Tinybit Inc. and what have you learned since then?

In the late 1990s, I worked as a freelance web developer. At this time, I mainly used Perl to build CMS-type systems (e.g. shopping carts, job matching sites). In 2000, as my number of clients increased, I started Tinybit Inc.

For years, we’ve been making and selling online journal aggregation/single sign-on systems for universities, hospitals, libraries, and think tanks. I’ve learned that the niche market is good with regard to this business. After I encountered WordPress, our company started using WordPress to make our clients’ websites. However, we hadn’t mentioned WordPress as our company specialty for a long time.

In late 2011, we moved our offices to Sapporo from Tokyo and reorganized our business line, finally finding our niche business in WordPress, which is “WordPress Support” (Sound too ordinary? Perhaps; but I rarely see anyone do this correctly.) The concept is support for everyone — from small site owners to WordPress pros — we help them in any way we can.

So far, most of the inquiries are from small business owners who build WordPress sites by themselves or small web-dev companies who build WP sites for their customers. A few years ago, none of my old clients knew anything about WordPress, but today in 2013, most of their corporate sites are built with WordPress. This makes me feel that WordPress has truly become the de facto standard for a site building tool. I think more and more professional helping hands might be needed by this new generation of WordPress users.

Tell us a bit about the project that you’re most proud of.

Running School+Q is a runner community featuring the Olympic gold medalist runner, Naoko Takahashi as a coach. The site is one of the first commercial use adoptions of WordPress by a big enterprise in Japan. It is also a successful sample of a multi-user blogging community.

Tell us about your involvement in WordPress Internationalization (i18n).

In short, WP Multibyte Patch is an i18n version of the hotfix plugin. The current version contains 15 enhancements and bug fixes for Japanese installs. Some people, like Andrew Nacin, suggested that I do this in Core and I think it’s a nice idea; but before we go too far, I think we need to research other languages and organize common problems and language-specific issues in order to determine the most appropriate way of implementation and one that will make everyone happy.

How has contributing to open source affected your work, life, and learning?

This is a difficult question. It has definitely changed the way I think and how I work with people, but, in reality, contributing to open source and business do not always go together. I still don’t know the best approach for accomplishing both.

What motivates you to stay active in the WordPress community?

I’ve known WordPress since its humble beginnings. The community is still growing fast and so many talented people are working hard every day to make the software better; I see no reason to stop watching it.

Customer service is more than just solving problems and making people happy they decided to use your product. Support is a form of art. How you shape customer service is up to you. Like Thomas Kinkade and Pablo Picasso before him, success in art is defined by crafting an approach that best connects with your patrons. The most beautiful thing about art, though? When you start with a blank slate, you can take it in any direction you want. And the same goes for support.

Some say "good artists are born, not made." But the masters in the Louvre didn't emerge from the womb with paintbrush in hand. They developed interests and pursued those, learning from their experiences to better themselves — and more importantly, their processes — over time. If support really is an art…why treat it any differently? Shouldn't you be able to come to the table with little more than passion for the cause, and carve your own style that spreads throughout the community based on how well it speaks to them?

Running support with a non-technical background

Just over two years ago, I joined Modern Tribe to help handle support for Events Calendar PRO.

The premium plugin was still relatively new at the time. Shane — our CEO — and I did a daily divide-and-conquer on the CodeCanyon forum. The only strategy we had was "make sure to respond before people get pissed off."

That much I understood. But beyond that, things were hazy. Coming into this role I had no experience doing dedicated customer service, barely knew a thing about Events Calendar PRO, and had only a working knowledge of WordPress itself. I could find a line of code in a PHP file but wouldn't feel comfortable making changes myself. I could fake my way through a conversation on Javascript or CSS but would freeze up if asked to hack at core files.

And guess what? It didn't matter…and still doesn't.

If anything, a non-technical support lead can approach customer service without the constraints of a developer's mind. A non-technical support person views things as the customer does, and can convey community wants/needs to the dev team in plain English. They force devs to consider and plan for the fact that not all users are developers.

There is a line that you need to walk: give the devs too much control, and they may build what they want without considering the community. Let the customers drive the carriage, and you're sure to veer from the project's core scope. You're probably going to run over budget, too.

At Modern Tribe, we call the support lead a "community advocate." Remember that it's hard to advocate for the community if you can't put yourself in their shoes.

Since taking that first pass at CodeCanyon, we've grown. Support has become a five-person team and is likely to get bigger in 2013. Shane's removed himself from daily support entirely, and I've stepped back to a management role so I'm not as involved in the day-to-day exchanges either.

My technical skill is not much more advanced than it was two years ago. Likewise as I build the team, technical accomplishments are one of my lowest priorities. I want people who care and empathize; if that means they need to bring in dev help for the more complex support tickets, that's a tradeoff I'm more than willing to make.

Why all good support teams also do Quality Assurance (QA)

If a support team isn't at least partially involved in the QA process, they're doing it wrong. With proper testing instructions even the least technical support staff can effectively run quality assurance testing to verify that something works.

Consider five premium plugins, each with a dedicated support forum that one team member manages. This person effectively "owns" that forum: they address all threads, report feature requests and log bugs to the core dev team. As those come in, the dev team works off this feedback to produce the next release. When it’s time to verify that the new code accomplishes what the community wants to see, does it really make sense to have an isolated QA team verifying that? Ultimately, who'd be the most sensible person to conduct testing here? Answer: the support team member who initially reported the problem. They know the problem, have a rapport with the user and won't have to waste time researching how to replicate the issue. What better way to expose your staff to the code they'll be required to support in the near future?

This is why it's always surprising to hear from teams who handle QA differently. Normally they fall into one of these categories:

• QA exists independent from the support team.
• The devs who did the work do QA. (You'd better be damn confident in your dev team if this is the route you take!)
• There's no real formal QA process whatsoever.

The merits of each could be debated…except maybe the last. (That's just foolish.) But all three create silos — independent, isolated teams working among themselves, which makes for a fragmented experience for the end user. By exposing support to QA, and having support teams increasingly involved in pre-release testing so that everyone knows what’s shipping, we've been able to do a much better job of accurately communicating to users…and setting their expectations on the scope or timetable for a given fix.

As an added bonus, we've found as we get the team more actively involved in the entire project cycle, everyone becomes more excited and willing to share their ideas. The situational awareness such testing offers helps the support team to work more effectively with devs just as much as it helps in their customer encounters. This works well with co-located teams. But what happens with remote employees?

Avoiding the pitfalls of a remote, freeelance support team

Whether QA is a factor or not, support momentum becomes more complex when everyone works remotely. Consider the fact that the whole team is part time and everyone freelances — meaning they've got other clients, too — and things can get messy, quickly. We've only got so much overlapping time in a given day and so we have a strategy for handling support.

No system — no matter how awesome — is going to keep a bad team from failing. If you've got support staff who are genuinely disinterested, view this as "just a job" or who don't share the customer's sense of urgency, then you've got bigger problems.

As a general rule of thumb: if a support member doesn't approach every new support exchange with, "How would I feel if I were in this person's situation?" then they probably aren’t well-suited for a remote support position. The amount of uncertainty — the sleepless nights you'll have wondering how much babysitting this person requires to get the job done — you don't want that. As with anything freelance, you want self-starters: good people who you can count on to get things done. And you'll be able to tell pretty quickly which side of that coin they fall on.

You will find good people — they're out there. Here are few things I've found effective at maintaining momentum with my distributed team:

• A shared commitment to 24-hour response times. This is pretty standard, and I question the dedication of any team who doesn't guarantee customers a response of some kind within 24 hours of the original post. We openly publicize this 24-hour window. It forces the team to stay accountable, because they know there is no gray area: if your forum has threads outside that timeframe, you've failed and so have our systems. And it's going to warrant a discussion you'd probably rather not have.
• Twice-weekly scrums. We meet for 30 minutes, twice a week, to review the support obstacles we're facing. Everyone brings up exactly what stands in their way and we figure out how to work through it on the spot. Everyone normally comes away with one to two action items outside of their regular support duties, to report back on at the next scrum.
• An active Skype chatroom. We've got our broader "Products" chat with the whole crew, but we also started a support-only chat a few months back. What a change this has made! It's like a never-ending scrum meeting where we can ask each other questions and pass off threads or support emails to someone better qualified. Plus, there's just enough goofiness and off-kilter banter that it feels as close to a watercooler as you're going to find in the digital world.

Despite the fact that I have never met three of the four support members on my team, we've developed working systems that are as effective as any established by comparable groups working in physical offices.

Turn support into a flexible creature

Different systems are going to work for different teams, and that's OK. This piece is meant to be an overview of what worked for Modern Tribe in case it might work for you too…and you're welcome to take a page from our book if it does.

But if I could leave support teams out there with one bit of advice, it's to try new things. Buck conventional wisdom. Go with your gut and accept that your idea might not work.

What I touched on here and — for that matter — virtually every aspect of Modern Tribe's support system does not come from a book or from reading articles like this one. It comes from trial and error: seeing what works, what doesn't and adjusting to make sure it doesn't happen again. If you're willing to do the same, you'll learn a lot.

Image based on Billetes y sombreros by Germán Póo-Caamaño, CC-BY-2.0.

How did you first get into WordPress, and (presumably later) BuddyPress, and what was it that pulled you in?

Like many, I went the hand rolled route to start blogging. It was somewhat of a “rite of passage” to develop your own. I was lucky enough to be a member of the blogging network 9rules back then. This was an amazing collection of people focusing on creating great content. A few others in this community were using WordPress when it was still a fledgling platform. I took a bit of time to be convinced I could do what I wanted to do theme-wise — but once I worked that out, the simplicity sold me.

BuddyPress was a slightly different story. I was creating WordPress themes and had a chance to create some BuddyPress themes. I had time to dive into what then was quite a learning curve to create themes. Over time as I learned that communities was where my heart was, my work reflected this passion and I moved to creating using BuddyPress full time.

When did you set up Logical Binary, and what have you learned since then?

Logical Binary was set up initially nearly 12 years ago as a way to showcase the work I was doing. It for a while was name only, my “web presence” only fully forming in 2005. I’d been doing freelance by word of mouth for a few years mixed in with agency work and needed a home online. Logical Binary, the site, grew from a need to take things a bit more seriously and focus on a business.

What I’ve learned over the years is to focus on what you love, and that niché is good. I’m not someone that can do everything — if you are then great but I design better when focused. Playing to my strengths is focusing on community design.

Talk to us about your strongly held belief in “design for humans.” Where can design go wrong when it loses sight of this idea?

I think my passion for designing for humans comes from my love of psychology, which I studied up to A-level and has impacted my entire life. Some of my first experiments on my own site were with theme switches by mood. It was a perhaps naive way of exploring back in 2006, but it was my first step outside of the single experience and thinking about who was using the site.

Design goes wrong when it assumes the operator at the end is the same. As a designer it’s easy to assume everyone will think like us — we’re not “every man.” I’m very into asking stupid questions of interfaces — this is when you see the gaps. Using the word “Submit” is a prime example — how unfriendly is that? Or a page that you land on with everything at the same level, everything shouting at you for attention. Where do you look? Our brains can’t handle it. We need paths, we need emotional feedback from what we interact with, we need guidance and we need common manners on sites.

You’re a heavy contributor to open source projects. How has that fed into your work life, opportunities, and learning?

I got my first taste of the ‘net from the Linux community many years ago. This was long before WordPress so when that showed on my radar I was already sold on open source. Whilst I’m not religious, I have one belief in life and that’s karma. I truly believe if I didn’t give back I’d not get anywhere near as much as I do in work life, opportunities, and learning. You truly do get out what you put in. The ease with which people share information is mind blowing and we should never forget how special that is.

I had the pleasure of attending BuddyCamp in Miami recently and it blew my mind. At one point I was told that there were several hundred people watching the live stream. This really filled me with energy to do more, create more, and get more people involved in BuddyPress. I truly believe that I’d not be where I was without the community, and I’m thankful every day for being part of this and those I’ve met. We’re united by a love for WordPress and BuddyPress, by an obsession with open source — this is a powerful thing.

What are you most proud of having contributed to BuddyPress, and what are you most excited about in terms of its future?

I’m most proud to have been able to contribute as a designer to BuddyPress. This may sound odd but it’s a misconception generally you have to be a developer to contribute. This is far from true of course. WordPress has blown this myth away but in some ways it hung around BuddyPress for a bit longer.

An exact contribution is tricky. I’m proud of organizing the default theme CSS file. I learned from looking at people’s code and hopefully this has helped other people. I’m also proud to have been part of the Status theme and Turtleshell project. I think above all I’m just stoked to be part of the BuddyPress project in a small way at this time.

I’ve described BuddyPress before, in terms of age, as starting school. It’s a young project but growing. I’m excited about getting more people involved beyond just developers. For BuddyPress to grow I really believe that not just developers should be part of its future and present. It’s really cool to see what can be built that isn’t using everything — maybe it’s just activity, maybe just groups, using BuddyPress as a platform, as an API and as a starting point to building a whole host of things with a dash of community — now that’s exciting.

As a specialist in BuddyPress, how would you explain the key benefits of making use of it over other alternatives a client or fellow designer might be considering?

BuddyPress, I’ve said before, is social lego. You can use as much or as little as you want. You pick the tools and create the community. That’s the big benefit at the start. You can, since the release of 1.7, do all this with a flick of a switch on your existing WordPress site. Default in communities only gets you so far. If you want to build, grow, and allow your community to take off, you need to go beyond default. BuddyPress lets you do this. It lets designers be free to create, it lets developers be free to build.

BuddyPress also has a very powerful community behind it full of passion, and an open sharing of information at its core. If you build on BuddyPress you get an entire community behind you from the start. I’m not ignorant to other solutions but no other option really allows for such ease, unique communities, and support of resources.

One of your many projects is buddydesignlabs.com. What were your goals in starting work on “lab” style projects, and how are they different from your contributions to BuddyPress itself, or the work you do for clients.

Buddy design labs is aimed at being an open-ended project for me. In it, I want to explore what could be for BuddyPress. I probably will develop some ideas into plugin form but I truly have no set goal. The reason I wanted to just indulge in pure speculation and exploration was that it frees me to think outside client projects. I’m not constrained by anyone’s requirements and that’s quite a powerful experiment.

The format I’m choosing is of a blog post. It shows my sketches and mockups and reminds me a lot of the sketchbooks we kept as art students that documented the work we did. In many regards that’s what this project is becoming for me. I used to love my sketchbooks and am growing as fond of Buddy design labs for the same reasons. It’s about musing, putting things out there, and seeing what happens.

You’ve worked with some really diverse clients. What would you say unifies them, and more broadly, what attracts you most in a potential client project?

Most get to me by word of mouth. I have to take a moment here to thank those who pass work on to me the BuddyPress core team specifically are amazing at spreading work among the community. Community is really the unifying element.

What gets me to take a project is understanding. Communities don’t just grow on trees, you have to understand their complexity and that there are no easy wins. Yes, it’s rewarding and powerful to have a community but it’s something that needs work. Not all communities are successful and sometimes I have to be honest about that to the prospective client and not take a project.

Out of all the work you’ve done, which project are you proudest of, and what challenges did it present to you?

I am most proud of being part of shift.ms. The current design isn’t my work but we’re going through a redesign and this is what I’m most proud of. As a client they’ve been very open to taking a step back and re-analyzing every part. It wasn’t an easy process but everyone involved had the community goals at the heart of every decision.

We’ve gone through focus groups, inspiration collection, wireframes, and are currently in the prototyping phase. I’ve had a lot of my own assumptions challenged during this process, too. The one that comes to mind is tag clouds. They’ve in many ways gone out of fashion; their users, though, love them. This backed up the fact that sometimes we should just ignore what is “trendy” and focus on the user. We’re brewing up some interesting takes on many traditional community functionality we’d have only thought of by going through this process.

Finally, you’re one of the organizers of WordCamp Europe. What’s the big idea there, and what are you most excited about?

WordCamp Europe is a celebration of the European WordPress community. It’s a two-day event in an amazing venue which several of the organizing team (myself included) visited for another conference in December. There’s a really strong community in Europe and we hope that this event highlights that.

I think I’m most excited about the focus being on Europe and showcasing all the amazing things we as a community do. I really think the time is right for an umbrella WordCamp like this.

Quick Overview

WPShout kicked off in 2009 and has been bringing a range of free resources, insightful opinion pieces, and useful tutorials ever since. With pieces on everything from the economics of premium themes, to comparison pieces on WordPress hosting services, with a side order of free ebook, screencast tutorials and more besides, it’s well worth your time.

Image based on shout by Krista Baltroka, CC-BY-2.0.

Do you remember when you first encountered WordPress, and the point that you realized it was something you’d work with professionally?

I first remember hearing about WordPress in the mid-2000s, when a few friends at CUNY were doing some pioneering work with WPMu. I used WordPress a little around that time while teaching Ethics to undergraduates: I had them keep philosophy journals on public wordpress.com blogs, which allowed for better peer review. In 2009, I was asked by my friend Matt Gold to help out for a few hours a week on his CUNY Academic Commons project. CAC was built on WordPress and BuddyPress (then in beta), and needed someone with some real technical chops. Despite this fact, he asked me to help. I knew nothing about WordPress or PHP when I started (just a bit of HTML/CSS). Within a few months, I’d written and released my first plugin. Within a year and a half, I’d quit my job to do WordPress consulting and development full-time.

You’re a Lead Developer for BuddyPress. How did you get involved with it, and what itch was it scratching (or not quite scratching) for you at the time?

I started using and developing for BuddyPress through my work on the CUNY Academic Commons. The team behind the Commons wanted to remain true to the for-the-public-by-the-public history of CUNY itself by using free software. At the time, BuddyPress was really the only social networking tool that was free (in all senses) and that integrated well with the other tools we wanted to use. When I started building features and fixes for BuddyPress, it was only fitting that the Commons leadership would encourage me to contribute them outward, either as distributed plugins or as upstream patches.

What are you proudest of having contributed to BuddyPress?

Much of BuddyPress’s recent development has been focused on transforming BP from a somewhat quirky, largely standalone system, to a robust, modular, scalable plugin that feels — both to users and developers — like a natural extension of WordPress. I’m quite proud of the work that I’ve accomplished toward this goal over the last couple release cycles.

In BP 1.6, for example, I made some modifications to the way that directory pages are built that reduced database overhead by up to 75%. In BP 1.7, I’ve replaced our aging, labyrinthine member query methods with a BP_User_Query class that is modeled on WP_User_Query, and improves query performance by a factor of three or more. These sorts of big changes — along with countless smaller improvements — make each version of BuddyPress more pleasant for the end user, more scalable for big-time implementations, and more approachable and fun for WordPress developers.

How important has getting involved with the WordPress community been for you, and how would you convince someone up against deadlines to give something back to that community?

My involvement with the WordPress community has been transformative in more ways than I can count. Working alongside numerous other developers has dramatically improved the breadth and depth of my technical skills. I’ve created a reputation and a niche that’s allowed me to be extremely selective about which clients I work with. I’ve met a lot of great people, some of whom I’ve come to consider close friends. And I’ve been able to contribute (however modestly) to a larger policital and philosophical cause that is extremely important to me: the development of software tools that allow individuals and organizations to reclaim pieces of their online lives from commercial entities and proprietary tools.

Nearly anyone who has done this kind of work in the open and has given things away — plugins, themes, tutorials, blog posts, forum support, whatever — will have anecdote upon anecdote about how this kind of openness tends to lead to unexpected and wonderful results. That said, I can understand why some are reticent about giving things away. We all have bills to pay. And, sadly, there is no cosmic karma guaranteeing that each act of generosity be repaid in kind — every developer of freely-available WordPress tools can tell stories about hours lost, and gray hairs gained, while interacting with unreasonable and ungrateful users. So, if someone were unconvinced that community work is the smart thing to do, I’d try to impress upon them that it’s the right thing to do: if every person who’s benefited from free software gave, say, 5% of their time back into free software, the world would be a far, far better place.

What was the thinking behind Commons in a Box, and what problems did it first set out to solve that weren’t being solved effectively elsewhere?

The CUNY Academic Commons has been a model for many colleges and universities, both conceputally and technically. But reproducing and customizing something like the Commons — built on thousands of hours of development, testing, trial, and error — is no small feat. The extensibility and modularity of platforms like WordPress and BuddyPress are what make them so powerful. But these same qualities also make it daunting to set up a complex system of interacting plugins, themes, and other modifications.

The goal of Commons In A Box is to ease these difficulties. Commons In A Box does a couple of things, on your behalf, that help you get from a blank WordPress installation to a full-featured community site. First, we provide a curated list of plugins that are powerful, and we whitelist versions of those plugins that are known to work well together. We then fetch and install those plugins for you. We provide a theme that’s tailored for academic and non-profit communities, and which provides a robust set of tools for customizing layout and appearance without knowing CSS. And we handle upgrades for those plugins and themes, so that you don’t have to worry about whether, say, a new version of BuddyPress will break your site.

In short, we provide users with a head-start: instead of taking hours (or days, or weeks) to research, install, and configure WordPress plugins and themes, one can quickly get to work fostering community engagement.

What have you learned through iterating on Commons in a Box, and what might you consider doing differently if you could start again knowing everything you do now?

Technically, I think that Commons In A Box is pretty solid. Ray was the primary developer of its core functionality, and did a fantastic job building something that can easily be maintained and extended. And our theme developers, PressCrew, built a theme that strikes the perfect balance between ease-of-use and flexibility, without making any sacrifices on elegant design.

My biggest challenges during the development of a relatively large project like Commons In A Box were related to management. Most of the time I devoted to the project was not spent writing code, but doing code reviews, managing deadlines, leading testing, handling communication, and so on. I discovered that, while I like (and think I’m good at) playing a leadership role in a public volunteer project like BuddyPress, leading a grant-driven project like Commons In A Box takes a whole different skillset. I don’t really have the chops, or the desire, to do project management for my day job.

With Commons in a Box, Anthologize, Participad, and in a lot more of your work besides, there is (or seems to be) a real emphasis on community publishing. Which comes first for you — community or publishing — or are the two inextricably bound together?

The core idea that motivates my work with free software is that users should have control over what they do and produce online. It just so happens that I came to software development through BuddyPress and WordPress, so that my professional emphasis has been on tools for web publishing and community. In another universe, I’d be working on a different kind of free software

That said, community and publishing software are particularly important insofar as they both enable kinds of activity that are central to the way we conceive ourselves: the things we write, and the connections we make with others. Those who develop these kinds of software, then, have a special privilege and resposibility to respect user freedoms.

What roles do you see WordPress and BuddyPress playing in the ongoing transformation of education, and does it make a big difference that they’re Open Source?

Education (especially the liberal arts college experience) is often described as the process of turning youth into citizens. When a student takes a course in philosophy or physics or history, she’s gaining a set of tools for participation in society, for representing herself and her needs in a respectful relationship with the world around her. The rise of free software parallels this conception of education in a nice way: things like WordPress and BuddyPress are tools that enable students to become fully realized agents, individuals with control over who they are and what they create.

From a philosophical point of view, it’s far more important that these tools are free (as in speech) rather than that they’re open source. Most students are not technically inclined, and the idea that their favorite piece of software was developed using a given methodology is probably not very interesting to them. What does matter is that free licenses like the GPL protect their rights to use the software as they see fit.

More concretely, the ideas behind free software are very much in keeping with the public-engagement goals of universities, especially public ones. That means that schools are, more and more, embracing free over proprietary software. This has a cascading effect: students are creating content using software they’ll continue to use after leaving the university; the university is free to modify the software however they’d like for their own purposes; development funds go toward hiring free software developers who are generally local to the university and sympathetic to its purpose, rather than toward huge licensing fees paid to faceless software companies. It’s an amazing trend, and I’m proud to be playing a role in it.

Do you see a point at which educational and other organizations will be able to ditch proprietary networking, teaching and knowledge sharing solutions for Open Source alternatives? What, if anything, stands in the way of that happening?

I think it’s already happening, little by little. About five years ago, the CIO of one of the CUNY campuses told me they couldn’t support WordPress because “they didn’t have a Linux person on staff, and they never would”. In the fall of 2012, I helped this same campus move its externally hosted, guerilla WordPress installation to a Linux server supported internally by the IT department.

Leadership in campus IT is extremely conservative. For university CIOs, “free and open source software” has traditionally meant software that’s insecure, feature-weak, unreliably, and — most importantly for them — unsupported. In the last few years, the zeitgeist has shifted, at the same time that free software itself has gotten better. The marketplace that provides services and support related to free software, from big companies like Red Hat and Automattic to individual consultants like me, has played a big role in making free software seem less like a gamble to
these very risk-averse individuals. People on the academic side of the university — faculty, deans, provosts — generally don’t need much convincing to be sold on the practical and moral benefits of tools like WordPress, so as CIOs gradually find the idea of free software more palatable, there’s a potential for the floodgates to really open on its use in universities.

Has working at CUNY afforded you development opportunities that you might not have been able to give time to if you working in, say, corporate or startup space?

Definitely. CUNY has historically been a very particular kind of social justice institution, catering to a huge underserved subsection of New York City. So it’s been a fantastic place for what I’d call “activist software development”: the building of tools that are conceived to suit our specific needs, but are also designed from the start to be given away.

As I’ve done more and more work outside of CUNY as a freelancer, I’ve found that this same spirit — the desire to serve through building — exists within educational institutions all over the world (though sometimes not as openly as at CUNY). I’m really pleased that I’ve been able to do contract work for a wide variety of schools, playing my part in spreading the good news of free software.

On a personal level, I don’t think I’d deal well with corporate or startup culture. I get bored easily, and thrive on learning new things and dealing with new people. My preferred lifestyle is to spend 30 or 40 hours a week doing interesting and highly varied work, and to spend the rest of the time with my family. Pumping out 60-80 hours weeks working on a single app as part of a startup? That’s a young man’s game

What are you most excited about working on next, and what would you like to see happen longer term for WordPress and BuddyPress in your context?

By design, more and more of my work has been about tool-building, rather than website-building. This kind of setup has worked really well for me, satisfying my dual desires to keep my work varied and to have maximum impact. I’m currently in the process of working with a couple of different colleges on new tools to make WordPress and BuddyPress work better in the academic context: from beautiful BuddyPress portfolios, to full-featured BP file management, to group RSS curation in WP. Beyond the next six months or so, I don’t know what I’ll be doing — but that too is part of what’s exciting!

One of the long-term goals I have for BuddyPress is for it to play a meaningful role in rethinking a truly distributed social web. Today, so much of our social content is locked up in centralized silos like Facebook and Twitter. BuddyPress eases this centralization at a small scale, by enabling niche communities, like schools, to set up their own internal networks. But I can imagine taking this idea even further. BuddyPress (much like WordPress already is) could be a tool for individuals to take control of the social content they produce around the web. BP could aggregate content you leave elsewhere — a comment on someone else’s blog, say — while federating with the BP installations of your friends and colleagues. The open standards that will make this kind of personalized, decentralized social hub possible are starting to mature, and I’m anxious for BP to play a role in putting this kind of control within the reach of the masses.

How did you get started with web development, and when did WordPress enter the picture?

I got caught in the web before the first bubble in 1999 as a teenager in Montréal. My first exposure to code was Flash Actionscript 4.

That was soon forgotten and I started teaching myself C#. I built a simple CMS out of it, only to move to PHP thereafter. By mid 2000, I put the project manager’s hat. I gradually dropped coding and concentrated on organizing teams.

WordPress first came to me while I was in the Congo in 2005. I entertained my first blog on a platform built by a friend.

The “5 minute install” promise of WordPress piqued my curiosity. I was quickly sold and I knew that WordPress would be a game changer.

Tell us about Wysija and the problem you’re trying to solve with it.

Wysija is a newsletter plugin for WordPress that was first released in early 2012. It’s a freemium solution.

Me and my 3 partners in crime wanted to fill a gap: what newsletter solution can be more flexible than Subscribe2 or Feedburner’s email alerts and yet, not force users to leave WordPress.

There were 3 challenges:

• build an easy to use drag and drop editor
• make the installation easy
• keep it essentially free

What made you decide to build a product on top of WordPress, rather than as standalone software?

There are dozens of great standalones. Great, but users want an integrated solution within WordPress.

Once you’ve trained your friends, family or clients to use WordPress, you don’t want to teach them yet another third party application.

How did you arrive at the business model for Wysija, and what was the thinking behind it?

For some reason, I can’t imagine another model than freemium. Here’s why:

• I’m personally averse to buying Premium plugins myself, believe it or not.
• We need a lot of users to quickly to build a better product.
• The “competition” already use freemium models.

How do the challenges of supporting a product compare to those of dealing directly with clients, as a service provider?

I grew tired of answering phone calls from clients. Consider me relieved at having a product instead of a service.

Supporting a product is very intense nonetheless. Yet, it’s quintessential to our success and I regard it as our number one marketing tool. When you have a product, it’s OK to make some mistakes, but it’s fatal not to respond to your users.

What pitfalls do you think entrepreneurs and designer/developers might face when making the leap from service to product?

Good question. I get it all the time at WordCamps. Many developers are tempted, and yet afraid to make the leap.

Here’s my own unordered list:

• Committing to your product is a full time affair.
• Underestimating support, or disliking it.
• Working alone, because having a partner is tricky, will get you nowhere.
• It’s about the experience, not the features.
• Your users know what they want, they don’t always know what they need.
• Yes, you’ll be poor for a while. But you’ll be exhilarated and happy.
• Sell from day one, don’t wait.

What’s been your approach to branding, telling your story, and setting Wysija apart from the pack?

Your product needs to speak for itself. Build an experience and user interface that is easy and fun. Your users should feel they’re using something special.

As an author, you need to be reachable and transparent. Humans love to hear about other humans. When people write to you, or ask for help, they are friendlier when they’ve seen your photo. Go to WordCamps, and meet your users — it’s gratifying.

Then, it’s all about service. Provide fast and friendly support.

Your website has to look professional so your visitors know you’re serious about it.

Acquiring users is difficult. Try to make every single one of them loyal ambassadors of your product.

What do you look for in a plugin or WP-powered product you’re considering using, and what makes you run a mile?

I look for plugins that have, in this order:

• Regular updates.
• High number of downloads.
• Support reputation.
• Best compromise between features and user experience.

What part, if any, has the WordPress community played in your work and the success of your business?

The WordPress plugin repository is how people find us. More than Google, word of mouth, and sponsoring WordCamps combined.

I consider the repository as the most important community tool because it offers the support forums, the reviews and star ratings. More importantly, it’s not commercial.

Sponsoring WordCamps hasn’t given us a lot of traction, but we do it nonetheless.

Talking at WordCamps has a definite impact. Then again, the crowd is composed of enthusiasts and hardcores. An infinite group.

WordPress is used by the masses. They’re actually everywhere around you, in your daily life. They are unknowingly part of the movement. I’m thrilled when I stumble on someone who uses Wysija, yet knows absolutely nothing about it or WordPress. This is when I feel we’ve reached the core of the community.

What are the three most important things to keep in mind when supporting a premium product or service?

Premium or free, you should always support your users with this in mind:

• Answer within 48 hours, possibly 24 hours.
• Be courteous and friendly.
• Get to the bottom of the problem and fix it.
• Ask for a review when finished. See our reviews, as example.

Additional tip: ever noticed how girls always say they’re sorry when you tell them something bad happened?

They’re right! Say you’re sorry, even if you have nothing to do with the problem itself.

What are you proudest about Wysija, in terms of really distinguishing it from the other options available for creating and maintaining mailing lists?

Its simplicity. This said, you still need to be a geek to configure it. This is part of our ongoing battle to add features while keeping it simple.

I’ll leave the last words for a Matt Mullenweg quote:

“The goal is to reach simplicity and not to be simplistic.”

Today we talk about how WordPress has changed over time, the merits and challenges of Open Source software, WordPress security, digging into the guts of WP, and more development goodness than you could shake a bundle of sticks at.

What was your background before coming to WordPress development, and how did WordPress first come into your life?

My first experiences with the web were at the very beginning of everything. In the early-/mid-1990s, I was the Systems Manager for one of the first ISPs in Huntsville, Alabama. Early on, we just offered dial-up access to a Major BBS system, which was connected to a Linux box, which provided gateway access for things like email, usenet newsgroups, file transfers, and a gopher interface. This was in the 0.99.x days of the Linux kernel, and the question of whether to pronounce ‘Linux’ with a long or short ‘I’ sound were just starting. And the World Wide Web was still an academic experiment that nobody had heard of yet.

But it wasn’t long before this cool new program called ‘NCSA Mosaic‘ started making the rounds, and the GUI interface for hypertext documents was much cooler than the text-based menus offered by gopher. Mosaic was followed by Netscape Navigator (and later, Microsoft’s Internet Explorer), we upgraded our systems, offering direct SLIP and PPP connections, ISDN service, shell accounts, and customers could create their own homepages.

It was in these early days that I first heard of this CGI script called PHP/FI. At this time, “PHP” stood for “Personal Home Pages” — it was only later that it was renamed to mean “PHP Hypertext Processor”. One of my first experiments was to use PHP and MySQL to create a database-driven news site for our customers, which I loosely modeled after Slashdot. It was my first blog-like system, pulling articles from the database newest-first, and displaying them ten-per-page. I didn’t even bother to make an article editing system, I just used PHPMyAdmin to add new entries to the database.

A few years later, we were starting to see open source blogging software. There were things like Movable Type, PHPNuke, Drupal, and even Slashcode which were fairly well known, and a lot of smaller projects. When I decided to set up a blog of my own, the first system I tried out was one of these lesser-knowns, named MyPHPBlog. I even became a code contributor to that project. But the lead developer was slow to integrate changes and push out new releases, and I became frustrated with it. For a while, I considered creating my own blogware from scratch, but I didn’t really have enough free time for that, so I was also keeping my eye out for other promising projects. I had started looking at b2, and it looked really interesting, but it seemed that its developer had more-or-less disappeared, and other people were forking the code already, or talking about switching to something else. I was already aware of this kid called Photomatt, and he was talking about forking b2 into a new system, with the blessing of b2′s creator.

So I think in March 2003, Matt asked me if I was interested in joining in on this WordPress thing he was kicking off. At the time, I was super busy at work, and replied that I just didn’t have time for it. But in April, things were a little more calm, and we were still exchanging emails about it, and I said that I could try to join in and at least contribute some ideas, if not code. Soon after, I was doing things like adding HTTP 304 browser caching support to the RSS feeds and expanding the XML-RPC API with support for the Movable Type and metaWeblog APIs. I remained an active core contributor for at least the next year or so. And I’ve tried to stay active in the community up to the present day.

As a “Developer Emeritus” of the WordPress platform, and a former Core Developer you added elements to WordPress, such as XML-RPC API support and Post Custom Fields, that are still fundamental today. Which are you proudest of?

I think I ‘d have to say Post Custom Fields. At the time, I was very interested in metadata systems, and I had been experimenting with things like FOAF (the Friend of a Friend data format) and other RDF vocabularies. When I first mentioned the idea of postmeta for WordPress, the other developers seemed to think it was a mildly interesting idea, but were not as excited about it as myself. I knew that it would open the doors for some really fun and interesting possibilities for plugins, though. But even then, I didn’t imagine just how many different ways people would end up using it. Eventually, we also got metadata for users and comments, too.

I’m proudest of that because I love seeing how many different plugins and themes rely on it now, and for all the creative ways people have put it to use!

What are you most and least enthusiastic about the way that WordPress has changed since you first got involved?

I am most enthusiastic about the massive uptake of WordPress. At last count, it’s powering something like 18% of the top 1 million sites? I think *anyone* would have to be impressed by that. And anybody who has ever contributed the least little bit of code or idea to WordPress can say, “I’m a part of that!”

I am least enthusiastic about some of the recent dogmatism we’ve seen over the “100% GPL” guideline for WordCamp contributors. I think the idea of barring someone from organizing or speaking at a WordCamp simply because all of their code is not available in a “100% GPL” fashion (e.g. in a split-license situation where the PHP code is GPL, and the CSS/images are under a different license — which *is* allowed under the GPL interpretations we’ve seen), is just too harsh, and only serves to divide the community.

It would be one thing to ask speakers to only promote “100% GPL” projects at a WordCamp. It’s quite another to bar them from speaking about *anything*.

You’ve developed and contributed several plugins to the WordPress ecosystem. Is that something you’d recommend doing, and are there any caveats to go with that recommendation if so?

I highly recommend it. Sometimes the simplest of ideas can take a life of their own and become popular. If you think of an idea for how to add a feature to your site, and can create a plugin to implement it, you might find that you weren’t the only person to want that feature. Declare it GPL, submit it to the plugin repository, and then have fun obsessing over the download counts!

The caveat is, on the internet, there are plenty of people with lots of time on their hands who like to point out faults in others. If you are not an expert coder, someone is likely to point out flaws in your code, and sometimes they might do so in a very unkind fashion. If your skin isn’t thick enough to put up with that, and you tend to take criticism of your work personally, it can be very depressing when somebody tears your code apart and tells you that You’re Doing It Wrong! If this happens, try to use it as a learning experience. Find out how to Do It Right, improve your code, and update. Life is all about constantly learning new things. When I first started learning to play trumpet in 7th grade, I sounded pretty terrible. But I practiced, and got better, and in high school I was in the symphonic band and marching band, and had solo parts. It’s the same with coding, and putting your code out for the public to see is like playing a concert in front of an audience.

As your career has developed are there certain types of projects or clients you’ve gravitated toward more, and if so how are those different to the type of projects or clients you were interested in a few years back?

That’s a hard question. I’d *like* to be doing full-time work involving WordPress. But unfortunately, the job market hasn’t been able to lead me in that direction. As a result, lately I’ve been gravitating more towards front-end work (JavaScript and CSS) than back-end coding. With the semi-exception that I’m also interested in the node.js server, though I don’t use that in my work, and I don’t have much time to play with it on the side.

In the past, I have stayed almost exclusively in the back-end of web development, dealing mostly with overall business logic, database interactions, integrating other data systems and sources, etc. But more recently, the browser has become a much more interesting platform in its own right. The power of modern HTML5, JavaScript, WebGL, and other associated bits makes for a very fun playground to explore.

You’ve presented (and will be presenting, at WordCamp Atlanta 2013) on WordPress security more than once. What would your top three tips be for locking down a WordPress installation, and more generally, what are the most overlooked security issues you see developers make?

Fortunately, WordPress itself tends to be pretty secure. Even when we do see point-releases for security problems, most of them have been ‘privilege escalation’ types of things, where you’d already have to be a validated user in order to take advantage of them. Random, anonymous internet users wouldn’t be able to get into anything.

Tips?

1. If your site doesn’t need the ability for new users to register an account, don’t turn that feature on. And don’t create user accounts for anyone that you do not *absolutely* trust. And when you do, only give them the access role they *need* (‘Contributor’, ‘Editor’, etc). If your site *does* need registered users, make absolutely sure that you have a backup system in place. Back up your database, and also any theme or plugin customizations, and maybe your media uploads if those are important. BACKUP, BACKUP, BACKUP!
2. If your web host makes you use FTP to transfer changes to your site, don’t do that (“You’re Doing It Wrong!”). Use a secure file transfer method like FTPS, SFTP, or SCP. If your host doesn’t support a secure file transfer method, it’s time to figure out how to move your site to a service that does. The FTP protocol transmits your password in cleartext, and while you might think the chances of somebody intercepting that information are small, I can assure you that it happens all the time, often to people who do know better.
3. If your web site is mission critical (whether for a business or just because it’s important to you), try to evaluate the reputation of any themes and plugins you add to your site. *For the most part* plugins and themes you download from wordpress.org should be pretty safe. Especially if there are a lot of downloads and good ratings. If there seem to be some bad ratings, read the forums and see if there are valid complaints that you should be concerned about. For third-party sources, if you aren’t sure of the reputation, ask around the community (on Twitter, in the wordpress.org forums, etc.).

Programmers don’t like to re-invent the wheel. Instead, we like to take an existing wheel, share it, improve it, re-share it, improve it some more, and so forth. This is how WordPress came to be. And because of that nature, WordPress contains within it a toolbox full of utility functions that solve common problems, ready for developers to use. This includes many functions to help you code more securely. One of the main things to learn about is the ‘esc_*()‘ family of functions.

Also, for plugin or theme option pages, learn about the Settings API.

Security is such a broad subject, it’s nearly impossible to convey the complexity to someone who doesn’t already have some technical background. You have to consider every piece of a system — not just the WordPress source code, or even just the themes and plugins you add. Because that all sits on top of PHP and MySQL, which have their own security concerns. And PHP is running alongside a web server, which might be Apache, Nginx, IIS, or something else. And those are running on a server, which might be one of several different flavors of Linux, or FreeBSD, or Windows, or who knows what else. And those servers might also be running other services, like SSH, FTP, email, IRC, etc. And if there are other users on the server, they might have installed other software that you don’t even know about. And there are the network routers, and load balancers, and the DNS system, and…! The internet is a vast system, and while individual pieces of it can be somewhat simple, they are woven into a whole that is extremely complex.

You continue to be active in the WordPress community, including presenting at WordCamps. What keeps you involved, and why would you recommend getting involved with the wider WordPress community to someone just starting out?

I suppose my continued involvement largely comes from the fact that I was fortunate enough to be so deeply involved in the early days of WordPress. I enjoy looking back and seeing how far WP has come over the years — how the features and interface have evolved. And even though I can’t always spend as much time working with WP as I might like, I also enjoy guiding newer community members to an “aha!” moment when they understand how to make WP do something they need.

The vast majority of the WordPress community are some of the most helpful and friendly people you could hope to meet. If you ever have a question about how to do something, all you really have to do is ask — on the support forums, on Twitter, the WordPress Stack Exchange, etc. You will generally get answers to your questions by someone who really knows what they’re talking about pretty quickly. And by using that opportunity to learn, and then later pass along some of your own knowledge to somebody newer than yourself, you have a chance to pay it forward.

What are the biggest benefits and challenges you’ve faced working with Open Source software? Does one outweigh the other for you?

The biggest benefit to working with Open Source, especially as a developer, is that I can modify the code however I see fit. There are very few closed source applications that let you do that at all, and if they do, it’s only if you pay a hefty licensing fee and sign strict contracts. As a user, you generally get the benefit that bug fixes and new features are released at a much higher rate than with closed source products. Since the source is available to all, many developers are able to investigate bugs and determine the best way to fix them.

The main challenge, though it’s lessened these days, has been getting companies to utilize Open Source alternatives to closed source commercial products. Most corporations are strongly attuned to Risk Management. With Open Source, you often (but not always) are not dealing with a centralized entity with contracts to hold them accountable should something go wrong with the product. Many companies consider this a very high-risk problem. You find it much less with the kinds of products associated with web development (web servers, database servers, browsers, etc).

You’ve previously advocated getting stuck into the guts of WordPress. What do you think are the least understood or most under-utilized aspects of WordPress as a platform, and how should designer-developers be making better use of them?

I’m not sure I have a good answer for that. I can say that some of the features that *I* am not as familar with as I’d like to be are the WP_Rewrite class, Custom Post Types, and Custom Taxonomies. I’d really like to find time to dig into those more, and find some interesting ways to use them for my own projects.

Maybe I can side-step the question a little bit here, and suggest that if you’re just getting started with learning to write plugins or themes for WordPress, you obviously have to start with the action/filter hook system. Find some simple examples to work from, experiment, learn the basics of those. Poke around in the WordPress source, and find places where it calls do_action() or apply_filters(). As you dig around, you’re very likely to see an action or filter that you never knew about, that might spark ideas for how you can use it for your own needs.

Once you understand the hooks well, start looking at the various files in the wp-includes directory. See how WP uses the walker classes, how the XML-RPC server class can be extended to add new API calls, how the image editor classes are used. Or you can start with your theme files, see how each piece of content is put into place, and what filters it goes through along the way. When you start looking at the code on your own to figure out how it all fits together, you are bound to learn something new and surprising. I can’t tell you how many times I’ve gone through the WordPress source, trying to figure something out, and said, “I didn’t know we had a function to do *that*!”

What’s the biggest difference between web development as a job and web development as a hobby? Can one feed into the other, or should they remain distinct?

Generally speaking, web development as a job will often limit which technologies and platforms you get to work with. On the one hand, by focusing on those core pieces, you will become very proficient with them. But on the other hand, web development as a hobby lets you explore wherever your interests take you. In my current gig, I’m dealing with Drupal, PHP, MySQL, JavaScript, and some of the more common parts of CSS. But what I’d *like* to be playing with node.js, websockets, WebGL, HTML5 canvas, CSS animation, and Arduino systems. And of course, WordPress.

I think for most people, the two do feed into each other. Obviously, the things you work on as a hobby outside of your job let you explore new areas. This can lead you to have new perspectives, new ways of thinking about and approaching problems, and this will almost always improve your overall skills and ability to do your job. And likewise, the focus you get through your work lets you gain a deeper understanding of your core tools. You get a similar benefit here because that strong reinforcement of knowledge keeps your skills honed and ensures that you are able to solve problems quickly. You can often extrapolate that knowledge and apply it to the new things you are trying to learn in your hobby life.