Changing Roles at WP Engine

For some time, I’ve felt there was a change coming and today, I’m ready to announce that my role within WP Engine is changing. Starting today, I have transitioned into an advisory and consulting role with the company.

Effective immediately, I will be taking the portion of the business that focused on professional services and consulting to allow the company to focus on premiere WordPress hosting. It’s a good thing and I’m excited about the possibilities. Back in November, we decided to start taking on some professional services work to augment demands from many of our customers. It was awesome to have fast, secure, scaleable, managed hosting but they wanted more!

And we wanted more.

However, as the company has evolved, taken funding, hired more people, addressed growth challenges and built out our hosting option, it seemed clear that the professional services portion of the company was a separate kind of deal than what we wanted to focus on.

So today, I’ll be taking that portion of the company (and all related existing and current relationships, as agreed on), and working on that. Meanwhile, I’ll still be working with the company to guide direction and strategy. So it’s good for everyone.

Effective immediately, I am available for all WordPress consulting roles. However, I am also currently entertaining all possibilities involving full time employment as well, and welcome those conversations.

To contact me, please direct emails to aaron@technosailor.com. As transitions go, the immediate financial impact is something that I need to consider.

How is WordPress Subversion Organized

svn


There’s some confusion about how WordPress organizes it’s Subversion (SVN) repository. Most SVN repositories are organized into three main directories, as is best practice — trunk, tags, branches.

The repository can be found at http://core.svn.wordpress.org/ and a primer on how to use SVN for WordPress development can be found on Mark’s blog and, for Windows, on Westi’s blog.

Though there are varying schools of thought as to how branches and tags work, WordPress follows the following system:

/trunk is where future release development occurs. Right now, WordPress development is focused on an upcoming 3.3 release. All development for this release is going into /trunk.

/branches is where 3.3 will go once it is released (or where future “branches” of the software will be housed down the road. The directory contains a series of directories that are branches from the current release development — for example, /branches/3.0, /branches/3.1, /branches/3.2, etc. What you won’t find in branches are security (or dot) releases.

For instance, when a security vulnerability is discovered, it will be patched in /trunk for the current development branch and may be backported to the previous release branch (currently, 3.2). But until the next security release of WordPress comes out for that branch, it is still considered “development” and not “stable”.

/tags is where stable releases are archived. No development goes into tagged releases. These are final releases. You will find every release here in the form of /tags/3.2.1, /tags/3.2, /tags/3.1.4, etc. If you’re looking for the latest current stable for production, this is the place to look.

When branches achieve the next milestone (i.e. a maintenance or security or “dot” release), this is the place where the code is kept.

Hopefully this makes the WordPress repository (and maybe other projects) clear as mud.

Rules for Entrepreneurs: Release Early and Often

hiwteboard

Last week, I wrote two articles outlining some philosophical ideas around entrepreneurship. This series of articles is all about giving away lessons I’ve learned throughout my five years as an entrepreneur in four different ventures.

When you’re in the product business, you have to continually improve on your product. As soon as you hit version 1, you’re heading for version 2. You create a roadmap and set milestones, which are just intermediary goals to help you get from inception to some point in the future.

The reality of roadmaps, however, are that they are susceptible to change based on market demands – or, as it’s sometimes called, “pivots”. You can have a great product idea that has a wonderful two year roadmap, but if customers don’t like it or demand other features that have never been thought of, then it would be wise to modify timelines and roadmaps.

Many successful products have been the product of a “release early and release often” mentality where the entrepreneur or product team did not wait to have a fully developed product, and instead, hurried to get something to market for the sake of collecting feedback and input and improving on the product.

Eric Ries in Lean Startup talks about principles of testing market validation by creating an iterative cycle of development where a product is released, tested in the market, feedback aggregated, assumptions tested against that feedback, and new innovation created as a result of those tests.

There are a number of rapid-cycle development philosophies including Agile, Scrum and others. These philosophies put a greater emphasis on involving customer feedback and direction over pre-determined plans where feedback is not collected until the development cycle is completed.

What happens if your assumptions were all wrong? Now you’ve got a product that no one wants to use!

The best way to avoid this problem is simply to release early, even before your product is near complete, and collect feedback along the way. Based on the feedback, you may need to modify your development trajectory but at least you’re able to do that before it’s too late and keep your product relevant to the consumer.

Next time, I’ll continue this series and talk a bit about business visualization to help you track your business and make effective decisions. If you’re not already subscribed to this blog, do so now. Also, follow me on Twitter where I’ll be talking about entrepreneurship, WordPress and a healthy dose of sports on the weekend.