Aaron Brazell explains:

Matt suggests (I think accurately) that a theme that is provided for WordPress (it does not work without WordPress) is a derivative work and requires GPL compatibility. He also suggests (accurately, I think) that GPL compliance would only enhance DIYTheme’s business as evidenced by countless other proprietary software providers who have gone open source.

I agree with Aaron’s parenthetical opinions, but have to add that the GPL’s extension is towards the PHP code only and that images and CSS  that comprise front-end may be licensed under another license. I also have to add that the GPL is extended to themes that are released “for distribution,” which protects my work when I develop a custom theme for someone.

Of the very few non-GPL-licensed theme developers, the most notorious is Chris Pearson, developer of the Thesis theme. I missed the interview mentioned by Aaron, given that it happened during office hours and I was at work, but I saw tweets, and it seemed the conversation ended on a very open-ended, but acrimonious manner. Chris Coyier has a (mildly humorous) summary. It looks like we’ll be seeing a court case soon enough.

My opinion on this matter, just as about almost everyone’s opinions on this, does not matter. What matters is that WordPress is a community project, and that the rules of game theory apply. Isolation in this project is worse than death.

I’ve been a critic of the WordPress project’s leadership, but never personally, and always on matters which I considered material and I’ve always tried to suggest, no matter how mean I’ve become, a course of action. A lot of Matt’s critics, however, are nihilistic and have nothing to offer. They don’t even have an endgame. They just revel in the power and authority that notoriety affords.

I have made my peace about the GPL-ness of WordPress themes. The safeguards to protect my intellectual property with regards to design already exist. I really don’t have much else to add, except that I personally would rather get back to work and leave this conflict to the courts.

As for Memorial Day: in keeping with this holiday, don’t expect me to greet or wish anyone a “happy” Memorial Day. Yes, many of us use this long weekend to spend some time with family, to celebrate the unofficial start of the summer, or to do other stuff. Let’s not forget that this day is meant to commemorate those who have fallen in our military efforts, if but for a moment.

I’ve been known in some small circles of the WordPress community as a very vocal critic of some decisions made by those whom we consider the leadership. I’ve written some zingers of analyses that have brought about ssome heated debate.

If it were only a matter of heated debate, I’d never have been led to writing this post. My recent response to some new guidelines on WordCamp organizing led to some very, very nasty discussions by others. Jane herself left a response in the comments and that was enough for me to close them. However, others took the post as inspiration to write even more unbelievably terrible commentary.

When I heard that Jane decided to show up at WordCamp Raleigh, I didn’t know what to think. I was hoping, however, for an encounter that led to a resolution for the better.

My conversation with Jane felt awkward, mostly because I was very ashamed that the conversation had to be had in the first place. A friend (who will remain nameless) had clued me in to the effects of my writing, no matter how “fair” or “intellectually honest” it could be. I was reminded that the developers aren’t really all that inaccessible.

I had to be reminded that there is a process to conflict resolution, and that motives really cannot be gleaned just on the basis of one’s actions. I’m very embarassed that I forgot about the three schools of moral evalution, especially since I wrote about them a while ago.

I’m moving on from the matters of GPL debates, and the conflicts between the “WordPress leadership” and other developers. I still commit to serve the truth, but the truth in this matter is that even my most fair and intellectually honest analyses will always be used as ammo by smaller minds.

No idea exists in a vacuum, and at this point, it’s better for me to channel my energy and ideas to other matters. I’ve asked Jane how I can help, and I’ve signed on to helping out with the UI/Design team. I requested no special treatment, and I fully intend to earn my keep.

This doesn’t mean I’ll be some shill with non-stop rah-rah “Automattic/WordPress/Matt/Jane/name-your-developer can do no wrong” cheerleading. Everyone makes mistakes, and I’ll hear and see things that I disagree with, but I know there are better means to address them, and taking it public should actually be the last, not the first, means of resolving an issue.

Finally, I must commend Jane for engaging her critics head on. She showed that she’s sporting a bigger pair than most of those who hide behind their computer screens. She spent a great deal of last Saturday engaging the prickliest of her critics, and have won over most of them, myself included.

First of all, here is my presentation on SlideShare, open for anyone to download and use. It would be nice to get some credit if you’re using it for another presentation, but you don’t have to.

Slide 28 has some suggestions for self-intiated study. The codex can be pretty arcane but not ununderstandble. In fact I believe that a lot of it is well laid out and there is a very sensible flow to the documents in the Blog Design and Layout section. As for that 101-level theme tutorial? ThemeShaper has a great one, and here’s one from ThemeTation, although the latter one starts with photoshop and ends with coding. I know quite a few people who start with coding and then patch in graphics down the line, so, pick your workflow.

I was also asked to put up a “Theme Developer’s Checklist,” and guess what? The codex itself has one, and I like it more than others that have popped up since. It is pretty much an “ultimate” checklist, and if you’re doing custom work for a client, you can probably pare off half of this.

Lastly, I did mention in passing to stop reading list posts and “design inspiration” lists that don’t teach you one bit, and read something you can learn. There’s A List Apart and as a matter of personal taste and design criticism, Joe Clark writes some very good design commentary, even though he doesn’t do any WordPress-related tutorials of the sort.

Thanks so much for the great response to my presentation. I am truly humbled.

UPDATE 2: Following a real-life conversation with Jane, this post is considered moot and have written a follow-up. This issue is over and done.

The problem with blanket policies [a very acerbic clause was removed on the advice of a friend] is that you end up causing collateral damage beyond what is, in retrospect, necessary to achieve one’s goals. The same holds true for writing policy statements that have wide-ranging effects on a particular activity. This morning, Jane Wells drops a hydrogen bomb on the WordPress community. The first paragraph is pablum, the second is where the bodies start vaporizing. I will scrutinize in a rarely-used format in tech blogging, called “Fisking.” (All emphases are mine.) Here we go:

One thing that we didn’t used to spell out but has become necessary to codify is that WordCamps are meant to promote the philosophies behind WordPress itself. Lately there have been a number of WordCamps accepting speakers, sponsorships, door prizes, etc from people/companies acting in violation of the WordPress license (GPL v2) with regard to their themes/plugins.

What is the tolerance limit here? When you say “with regard to their themes/plugins,” how do you know? What’s the disqualifying standard? Is it: “all themes/plugins made by a speaker/sponsor/door prize provider have to be GPL v2,” or is it “some themes/plugins” or is it “at least one theme/plugin”?

It is the official policy of WordCamp that WordCamps not provide publicity/a platform for such individuals/businesses.

“WordCamp” is an entity now? I understand that Automattic might want to claim the name as a trademark long after the fact, the way a “tweet” has been filed as a trademark by Ev. Ambiguous language.

They are welcome to attend, but WordCamps may not have non-GPL-compliant people as organizers, sponsors, or speakers.

So, there goes Microsoft and their wads and wads of cash that they handed to WordCamp NYC. Too bad it would be nice to court their sponsorship with every WordCamp, but oh well.

Events that want to move forward and include such individuals in these roles may need to use a name other than WordCamp if the appropriate adjustments can’t be made.

This preemptive declaration of personae non gratae is disturbing.

This is because WordCamps are seen as the place to gather for the official word on all things WordPress; providing a public platform and publicity in an official capacity for people acting in direct opposition to the official word just causes confusion.

Individual WordCamps already warns sponsors and speakers that is not “pitch time.” What is this “official word,” and why does the presence of non-GPL “people” assume “direct opposition?” If a commercial, non-GPL plugin or theme developer wants to present at a WordCamp about something that gives them no additional exposure aside from their work being mentioned (e.g. said person wants to present about CSS, or an improved workflow, or wants to share about how WordPress changed their lives) does that make them unwelcome? By Jane Wells’Standard As Of May Nineteenth In The Year Of Our Lord Two Thousand And Ten, Anil Dash would’ve been unwelcome for the keynote event in WordCamp MidAtlantic 2009.

I have no problem with the last paragraph so I’m leaving it out. Now, a message for Jane. This is going to be stern, but I’ll keep it professional. There is NO room in official policy for “common sense.” It’s for this reason that when you want the top brass of the strongest military in the world to spend a shit ton of money on your brownies, you have to follow a 26-page recipe (PDF) that spells out very specific policy, down to the last standard of what nuts may be used. Official policy statements are like that. Having worked in government sales, and having filled up immigration forms to legally enter this country, ambiguity is the enemy. Now that you are the official liaison for all WordCamp organizing, you’ll learn that while it would be nice to have your word as the Law Of The Land, there will be people like myself who will challenge you to make your statements clearer. I want to organize a WordCamp one day. I do 100% custom work, and the only “theme” I released to the wild is a palette-swap of Classic, back in 2003. I license all PHP in my work under GPL, but not the CSS and images, so my clients won’t turn around and give away a custom work I made for them. Does that disqualify me? Will I have to disqualify someone who made one commercial, non-GPL plugin?

Laying down the law never means having the last word. It means leaving oneself up open to questions. While I may be “just a guy” I know the questions I pose are fair and I would like to get an answer, preferably blogged by Jane on her own site, that more people will see her response.

Right now, the menus are, de facto, tied into the new default theme, Twentyten. This is because the CSS rules governing the appearance of the menu is coded into the theme’s style.css. The menu itself is called using the function, wp_nav_menu, but that outputs the list, nested as necessary, without any inline CSS.

Herein lies a dilemma: what if you are a fledgling theme developer and you didn’t know about that particular set of facts? What if you’re a user who’s used to downloading themes from the repository and the theme you happen to like is no longer supported or updated by its author? You’ll have this set of features in the back-end, “Menus,” that doesn’t appear to do anything!

At first I thought that hooking the CSS into wp_head would work so that all themes would have menus and the required styles, until I realized something about CSS’s hierarchy: code that appears last takes priority. No amount of editing in the style.css would work unless it’s attached after wp_head.

So here’s the suggestion: a script/routine/whatever that checks for the presence of a WP3.0 Menu, which then checks for the wp_nav_menu across all theme files, which then checks for the menu selectors in all .css files in the theme directory. Reminder messages (red or yellow, whatever) appear in the admin screen depending on what’s missing:

• “Menus are WordPress 3.0′s newest and greatest feature. You should give it a spin.”
• “You have a Menu saved, but it won’t show up in your theme unless you use wp_nav_menu. Here’s a link to a few suggestions on how to do this.”
• “You have a Menu used in your theme, but you have no CSS rules to make it look good! We’ve got sample blocks of code that you can copy and paste into your style.css.”

Or something along those lines, and I can already think of a few objections, the general themes of which run in almost any open-source project:

• “Everyone will child theme off of 2010.” <-- UH, NO.
• “Why would anyone need a warning like that?” <- Yes, open source elitists still say this shit.
• “If you’re a theme developer, you need to keep track of these things.” <-- Exactly, and the warnings are there to help.
• “Not enough people will benefit from this warning.” <-- This one is particularly dangerous.

Leland of Themelab also suggested in an email that the Menus box be enabled on the Theme level; that a function that turns it on be required in functions.php. This sounds like a good idea, too.

This situation elicits a little regret. Ive used WordPress since it was b2. I’ve seen its features evolve and I’ve built a great side business using it as a quick and efficient (not necessarily easy) way to deploy a front-end design. In all this time I’ve been in total remiss at learning PHP, the ins and outs of the development cycle, and the culture around WordPress. If I have, I’d have submitted this as a patch and fought for it. So before anyone tells me that I should submit it as a patch instead of shouting it from the rooftops, as of right now, I can’t quite do much else. That doesn’t mean that my idea is invalid.

A lot of the focus on Twentyten is on new features such as WooThemes navigation (which is available for all, if you know what you’re doing). Aaron Brazell recommends child-theming Twentyten, which is not a bad idea, but I think there is room for improvement in the final. I’m writing this because it’s an Alpha version, and there’s still time for someone with the PHP knowhow to do this.

Twentyten uses conditional logic in loop.php that references Category names such as Asides and Gallery. Not a bad idea, except the installation does not populate those Categories. I’m certain that there can be safeguards to overwriting existing categories when this happens for an upgrade, but if you’re going to take dibs on category names, at least populate those names or have a friendly (yellow) reminder up top that tells users “in order to make the most out of your theme, please create categories with the following names: Asides, Category, YourMomsKnickers.”
This is what I talk about when I discuss “thoughtful theming” in casual conversation.

I don’t know how to commit these suggestions or if it will even be an idea well-received, but it’s definitely worth thinking about.

I’m not a plugin developer, nor a theme developer, or a pure front-end designer. I honestly don’t know what to label the gestalt of my skills, but I do good work. Part of that good work is being able to select which plugins work for my project requirements. While I truly appreciate the good intentions of the WordPress leadership in bundling plugins together and endorsing them, but I have my fears on its effects on the plugin marketplace.

It’s libre in more ways than one. Let’s keep it that way.

The current state of the marketplace follows the standard distribution of players based on power laws. Right now, very good plugins with even better promotion and marketing dominate the marketplace. Is there a better plugin for a given application? Yes, but for reasons beyond the control of the WordPress leadership, they don’t get as much exposure. These reasons vary. The developer may be an asshole. Updates may not be frequent enough to keep up with WordPress’own development cycle. The plugin may be very esoteric in application. Whatever the reason, this hypothetical “better” plugin lives and dies without the interference of the leadership. The only thing more American than the WordPress plugin and theme marketplace is apple pie.

Releasing canonical plugins and themes, while making it easy for end-users and new adopters, interferes with that dynamic. Today, If I were to release Richmond—the theme running this blog—into the wild, I will have to compete with the awesomeness of Studiopress and Woothemes. If the WordPress Project were to include a theme similar to mine, not only do I have to compete with everyone else, I’d have to compete with God Himself.

“Canonical” “anything” is a takeover of a market that doesn’t need it.

I’ve always defended the WordPress Project and especially Matt himself from accusations of others that he’d rather not let anyone else make money off of this. Mark Jaquith is proof positive that one can make plenty of hard-earned cash from playing within the rules of the open source game. However, these “official” add-ons are a deathblow to innovators, because WordPress’expansion has evolved the market into a consumer one.

The bar to entry is low: it’s easy to set up a blog, find cheap hosting, map a domain name, etc. The users, however, have gotten lazy. When only 75% of users at a WordCamp are using the latest versions, we have a problem. Using a simple extrapolation—of course, not a statistically perfect method—of that number, assume 15% of the market is running outdated, insecure versions of the software. That’s a huge problem, considering the number of WordPres blogs out there. While I strongly believe that it’s one’s responsiblity to maintain and update a site, that assumed number is that of irresponsible blog-owners who present a danger not just to the reputation of the WordPress community but to the general online health of all online people.

These same lazy people are the ones who won’t be bothered to pick a plugin based on how it performs. They’ll reach for the closest solution accessible and go with it. In today’s plugin/theme marketplace, the market leaders may not be the best of best of the very darned best, but they come close. In tomorrow’s canonical marketplace, the majority of users won’t be bothered to move beyond that which is canonical. Why would they, when those selfsame plugins and themes carry not just the approval that a theme is safe, but that it’s endorsed by and is considered “official” by the WordPress leadership itself?

Leave us to squabble amongst ourselves.

God Himself limits the miracles He performs, because He has given us the ability to affect our world because of our will. The free market of plugins and themes is a beautiful thing. It forces the likes of Studiopress and Woothemes to innovate ahead of the market, or lose their edge. It forces me to refine my projects or lose relevance. The miracle of canonical plugins would end this. Perhaps not overnight, but it will. I implore the decision-makers at the WordPress Project: this is not change we need, nor is it change we can believe in. I understand that the opinions of end-users are important, but this still is a community-driven project, and a canonical marketplace—or better yet, a Command Economy—would have us fighting for the favor of the leadership, and not our clientele. That’s not a marketplace; that’s a clique.

Ma.tt responds:

Hey Jay! I’m always happy when you write about WordPress. 

First a disclaimer: I’m probably one of the biggest free market nuts you know. In fact in college I focused on economics and political science/philosophy.

That said, I didn’t finish, and let’s be honest I wasn’t the most studious guy in the world. Maybe I missed something important. Although I’ve thought about this issue endlessly, including most of the issues raised here, there are some things brought up in the comments that I haven’t thought about before. More importantly, you could be right.

That’s why we’re doing this whole thing as an experiment; not the Large Hadron Collider type that could potentially destroy the universe, but more incrementally with just three initial plugins.

The first, health check, is one that’s entirely new, a collaboration between some existing core folks and some new contributors. The second is existing core functionality, post by email, that we’re taking into a plugin to make core lighter, faster, and less bloated. Hopefully it will improve significantly too because we’ve got some really cool new code from it being donated from the WP.com side. The third, PodPress, is an existing plugin that is very popular in the community and provides important functionality but has effectively been abandoned, so we’re going to adopt it and modernize it so people who rely on that plugin aren’t stuck on old versions of WP.

Something new, something old, something borrowed… something blue? Yep: Kubrick. 

Now if in the course of working on these three plugins it looks like we’re going to cause the end of WordPress as we know it, we’ll change course. It’s not that big a deal, and we’ll figure something else out. The only dangerous course of action is doing nothing at all.

That’s a load of bullshit. First, on the matter of support, the GPL states:

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

You know what that means? That means that if you use this software and it’s not designed to cause damage but doesn’t work the way you want to, then you don’t have anyone to sue in court. It’s for this same reason that wars over GPL product are fought in the public sphere. In this field, the only currency is reputation.

It appears that as a FLOSS project grows, more people hate the developer, and to a greater degree.

As word of mouth increases the exposure and value of a GPL project, expectations grow to unwieldly proportions. The heart of any project is its community, and a project’s success hinges on the contributions of its members. More people with less knowledge about the full functionality and operational methods of the project are enjoined to use and benefit from the project, but these are the people with the largest expectations.

When they complain, they’re the same ones who speak the most hurtful words. They come only second to the competitors of the product in question. (On a side-note, I was guilty of this in earlier years when I had Movable Type in my crosshairs, and so are Habari advocates today.) Developers can be sensitive types. Hello? We’re people too. We produce projects that we believe solve a problem, and we take pride in the hours of voluntary service that we offer.

However, we, too, can be spread thin.

As expectations grow, so do the number of support tickets, and the many esoteric issues that appear in exotic situations that we are unable to predict. It’s even worse when we are unable to duplicate the problems. This is why, in front-end development, I have chosen to charge extra for IE6 consistency. For too long I’ve avoided PNG transparency to the detriment of my designs, just to make them “look the same in IE6.” No more. This is why, when setting up a site from the ground up, I charge extra for extended support and ensure that any issues with the hosting company are addressed to the right people.

When we’re spread thin, we start running out of time for those activities that make money for us. Designers and developers have a strong tendency for focus, and for that very same reason that most of us are dudes. Complaints are distracting, and being the exacting perfectionists that we can be (to a fault), sometimes we end up ignoring the projects that make us money. Then we get a little hungry, and start hating all of you.

A paywall is one of the best ways of diverting the flood.

Michael Torbert released All-In-One SEO Pack, and it’s become the most heavily downloaded plugin in the WordPress repository. It’s also one of the most misunderstood plugins in the world. No, it won’t make your site the number one result in Google for the word of your choice. It helps one manage keywords and titles and meta content in a way that WordPress by itself does not provide. For example, if I wanted to add a few keyphrases to the title attribute of this post without having a kilometric title in the post, AIOSEOP lets me do that. The expectations behind the plugin are some of the most unrealistic I have ever seen, and the complaints regarding the results and functionality have gone beyond the absurd. Too many questions asked at the forum are moronic, and many questions have been asked and answered.

The release of AIOSEOP Pro and the impending sunset for free support from Michael or myself have thrown a number of folks in a tizzy. The Pro version removes any advertising associated with the plugin, which can be seen in the plugin management screen. It also provides access to a support forum that will replace the free one. I have not advised Michael on any course of action. However, I understand completely why he’s doing this. The form fields for AIO are self-evident, and the installation is standard. The documentation exists. The paywall creates an agreement between him and the client, who sees value in the support that will be provided.

Value is perceived by the buyer

The grumbling is due to the fact that there is no extended or additional “functionality” associated with the pro version. The free version is supported by ads, but also works the same way as the pro version does. This is the same for the XML sitemap plugin (developed by someone else). This is the same case for a number of gratis iPhone applications and games. There is value in removing advertisement for a client project. There are people who will find this important. These are the people who will be willing to pay, and won’t spend the day complaining and calling the Pro version a “ripoff.”

Since I see no advantageous value in buying a car from Chrysler for the purposes of moving from point A to point B, I didn’t buy my first car from Chrysler. But I didn’t go complaining about how Chrysler is a rip because I see no benefit in having one. The most vocal of critics are doing this for two things: they want their freebies and/or they stand to gain from lambasting someone else.

These graceless little cockroaches are armed with the largest fucking bullhorns on the planet and get audiences that are disproportionate to their value as human beings. However, sunlight is a great disinfectant and the best way to deal with them is to shine a light on their stupidity. Hence, this post.

First off, the following fields only show up when editing a Page: Title Attribute, and Menu Label. B and C in the following screenshot:

Screenshot: AIOSEOP Menu Label Input

What you place under Title Attribute is output in the HTML as, quite obviously, the title attribute for the link on your menu. You usually see it when you hover over the link with your cursor. (I honestly don’t know how it works in mobile browsers, screen readers, or any other device without a mouse.) What you place under the Menu Label will replace the actual Page title in your wp_list_pages generated list. What follows is a screenshot of the output:

Screenshot: AIOSEOP Menu Label Output

And there you have it, folks! It’s a quick and easy tutorial on a new feature for the SEO pack, perfect for taming that pesky menu.