I’ve been collecting questions for the last few days for an O’Grady-style Q&A on Carrington Build.

Is Carrington Build a plugin or a theme?

Carrington Build isn’t a traditional WordPress product (a single theme or plugin). It is probably best thought of as the foundation or feature of a theme (for example, a component of our Carrington Business theme) because the best results will be seen with tightly integrated CSS and theme styling.

How does pricing work/why is Build so expensive?

We’ve tried to set up the pricing structure to reflect the value it provides and do so in a way that is appropriate for each group of folks who will be using it (end-users, WordPress professionals, commercial product developers). I’ve written a more detailed post about the pricing structure here but it’s probably best to refer to the official FAQ (this one gets updated).

What about people who run a network of blogs (multiple sites) and want to integrate Build into all of the sites, perhaps in several different themes?

We don’t have a set pricing structure for this use case yet. We’ve discussed needs with several people who have this situation, but I don’t think that we have enough information to create a policy that will work well in a general case yet. If this sounds like something you need, get in touch and we’ll figure our something that makes sense.

What is the license for Carrington Build?

All of the products I’ve released for WordPress (personally, or through Crowd Favorite) are 100% GPL; some are also commercial (including Carrington Build and the Carrington Business theme).

What about the claims on Twitter that Build isn’t 100% GPL?

You can’t believe everything you read online.

Sure, but what about the license he linked to?

We strongly considered using a split license; even went to the effort and expense of having the C2GPL license created during those deliberations. The purpose of the C2GPL license is to create a commercially viable and defensible environment for a product while staying GPL compliant and providing many of the user freedoms that the GPL does.

Why did you consider using this license instead of 100% GPL?

There are a number of reasons. We have a huge financial investment in Carrington Build. You can measure an investment like this in hard costs, opportunity costs (revenue lost while creating it) or any other number of ways, but any way you slice it we’re 6 figures into it. It is important to me to make sure it is commercially viable, not just to recoup development costs and hopefully have the product be profitable, but more importantly so that we can easily fund future development. We have a long list of features we want to create for Build. The WordPress community isn’t the same as it was yesterday. Today’s WordPress community is well served by commercial products.

Can you expand on that last point?

Over the years WordPress has evolved from a DIY/hobbiest package to a polished CMS with very little barrier to entry. As a result, the profile of a WordPress user has changed, today’s typical WordPress user is not a developer who wants to tinker with the code. Today’s typical WordPress user is someone who just wants things to work, wants access to customer support when needed, and wants to see new features added over time. Commercial software models work well to achieve this.

Isn’t a split license bad?

I don’t think it’s inherently evil, though others will certainly disagree with me. I think it’s dangerous to argue about the spirit of something. There is a lot of room to for interpretation about the spirit of a license. Ultimately it’s a legal document and we are bound by the letter of it, not the spirit. Practically, using a split license would make some things more difficult. For example, if someone wants to create a commercial theme with Build and release it as 100% GPL, that wouldn’t be possible if we had released Build under a split license.

So why did you create a split license and decide not to use it?

The reason above was important, but really I wanted to go GPL the whole way. I also want to be able to ensure that the product is financially viable. I’m still not completely sure we can do that while being 100% GPL, but we received assurances that this wouldn’t be an issue and we’re giving it a chance. I’m cautiously optimistic – I know that the value proposition is very fair, and we’re working to provide great resources for our customers. Hopefully this proves to work nicely and becomes the first of many commercial GPL WordPress offerings we release. It will largely depend on how the community responds and embraces Carrington Build and Carrington Business as commercial GPL products.

Why not just sell support? Isn’t that the Open Source way?

We certainly are providing support, but the better your product/documentation/etc., the less support people need. The normal reward for creating a great product is lower support costs. It seems people want to suggest the opposite system here. We want to create a high quality product and charge a fair rate for it. If this works, we’ll invest more in this type of development around WordPress. If it doesn’t, we probably won’t (and I don’t think others will either). I think that would be a real shame.

People are referring to Build as “game changing” with potential to “revolutionize WordPress development“, do you agree?

We’ll have to wait and see on that. I hope so; I definitely believe it’s one of the biggest development efforts for WordPress to date.

Why do you think that is?

A couple of reasons I guess. Firstly, the group of developers that has the kind of experience with WordPress to identify this as a problem and conceive of this type of solution (integrated the way it is) is a fairly small group. Of those folks, only a handful have development shops big enough that they can absorb this type of speculative development investment in a product. I’ve spoken with other WordPress dev shops about creating products in the past and there are a few reasons they have given for not wanting to invest too heavily. One is the license concerns and commercial viability discussed previously. Some have also expressed concern that their work would simply get rolled into WordPress core and they’d never get a chance to make it a profitable product. If we can prove that the commercial GPL model works for large scale product offerings, I think it can really open up the door to what WordPress developers can offer the community.

Several people have already talked about having Build added to WordPress core, can we assume you are against that?

For now, I don’t think it’s the right thing to do. There are a number of reasons, here are a few. Build is very young compared to WordPress core, it needs to evolve on a different timeline than the WordPress core release schedule. By keeping it separate, we can roll out feature additions, bug fixes, etc. without worrying about the full WordPress release cycle. Another reason is that themes are already getting more sophisticated and adding more and more features. I’m not sure that tight Build integration is something that all themes should have to worry about – not every site needs it. Also, I want to see a return on what we’ve invested in it.

Wouldn’t it be best for the community to roll it into WordPress core so that everyone can use it for free?

I don’t think so. If developers see that it isn’t financially viable to create something like this, very few will be willing to undertake it. Look at the gold rush for the iOS app store. Developers aren’t flocking there to give things away, they are building for the platform because they think they can make money at it.

On your blog, Ed suggests that Automattic should buy this from you and roll it into core. Would you be open to that?

I’d certainly be open to discussing it, though haven’t had any indications it’s something they would be interested in. Don’t get me wrong, I want to get Build out to the community as widely as possible. I actually feel that this is what I’m ultimately giving it a chance to do by making it a commercial product.

You’ve talked about the cost of creating Build, why did it cost so much?

Releasing software properly is hard. I don’t know that you can really appreciate it if you haven’t done it before. Here’s a partial overview of what went into the creation of Carrington Build:

• Come up with the idea and polish it, which took years of experience building on WordPress and years of listening to client requirements.
• Architect the WordPress integration for optimal developer flexibility while making sure it used only standard WordPress data storage, APIs, etc.
• Design the end-user interaction, creating a UI that is flexible and extensible.
• Architect a system to support the row and module concept, and how those components interact together.
• Use best practices including internationalization support, lots of developer friendly hooks, etc.
• Implement the core system.
• Implement rows, and the individual rows.
• implement modules, and create each module.
• Roll out on client projects, revising extensively for real-world use cases.
• Create (and maintain) example theme/reference implementations.
• Create (and maintain) documentation, for both end-users and developers.
• Create videos to try to explain how everything works.
• Create demo site and sample data so people can give it a real test drive.

If you really care about what you’re putting out there, you’ll be making lots of revisions, tightening things up and adjusting things that were created before new features and additions influenced how other features work, etc. And if you do it all right, it looks effortless.

Can Build be integrated into an existing site/theme?

Definitely. We have done several reference implementations into existing themes so that our Developer and Royalty Edition customers have good roadmaps to use (besides our Carrington Business theme). Our WordPress HelpCenter team offers a Build integration service and Sprout Venture is offering these services as well.

Can I make my own modules?

Absolutely. We created Build to be extremely flexible for new modules and features, after all we are our own customer here.

Is it easy to create a module?

Yes, think widgets – with a little extra functionality.

Can I include Carrington Build in a commercial plugin/theme?

Certainly, that is exactly what our Royalty Edition is for. Contact us for details.

In Carrington Business, Build is restricted to pages, can it be used on posts and other custom post types?

Yes, the list of allowed post types is a simple array that is passed through a filter, so it can be customized on a per-site or per-theme basis.

You mention that the data is stored using WordPress data structures, how do you do that?

The data is stored efficiently in custom fields so that it “just works” and should be pretty future-proof.

If the data is stored in custom fields, does this break search?

No, each module implements a way to provide a “text value”. These are put together and stored in the normal post content so that things like search and excerpts work just as expected.

Does it upgrade well?

We have only tested from 2.8 to 2.9 to 3.0, but so far there had not been any issues. We can’t tell the future, but since it uses standard WP data structure and hooks it should be quite forward compatible.

Is Carrington Build internationalized?

Yes, as is Carrington Business.

Is it compatible with QTranslate?

Not out of the box, but I think we could get it there without many changes to how Build works. It would be fun to get that type of integration created.

I am a bit confused about Carrington Build and the Carrington Framework. What are these?

Yeah, it’s a a little confusing, especially since the term “framework” was co-opted to mean “parent theme” by folks who don’t really understand development frameworks. The Carrington Framework (released in 2008) is a template selection engine that allows you to replace conditional PHP coding with simple template naming conventions. Carrington Build is our advanced layout system. I think in the future you’ll see us refer to the Carrington Platform, which includes Carrington Build and Carrington Core (the template engine). Hopefully that will make it easier to understand going forward. We have a bit of clean-up to do in order to reinforce this naming change in a bunch of places.

How is Carrington Build different/better than Product X?

I’ve been really surprised at how many people have emailed and asked this, and then been upset when I don’t want to engage in this discussion. I have no desire to disparage other products and I know my product much better than others so I’m really too biased anyway. I’d rather let other folks make those types of comparisons.

Anything else?

Lots of stuff, but this post is already way too long – we’ll save the rest for later. Thanks for reading.

This post is part of the project: Carrington Build. View the project timeline for more context on this post.