Tag: open source

Joomla World Conference

I’m attending Joomla World Conference in Boston this weekend. Wait, what?

WordPress founder Matt Mullenweg is giving a keynote address on Sunday. I’m really glad we’re here, as engagement across communities is vital. Too many web communities are isolated, and I suspect there is a lot the WordPress and Joomla communities can learn from one another.

The two projects have a lot of similarities: we love open source and the GPL, love-hate PHP, and have sprawling communities and ecosystems. We’re also both forks of other software (b2 and Mambo), and we are both trying to advance and evolve quickly, as well as better define what exactly we are (blog/CMS/platform/framework). Of course, there are many differences. I especially want to talk about and compare development philosophies. I quote from and reference our philosophies document often, and we practice them as much as we preach them. Among them: making decisions instead of adding UI options, designing for the majority of users, stressing the importance of deadlines, and building something that is lean, fast, and works out of the box.

We receive a lot of praise for our user interface, and we strongly believe that the user experience comes first. But for us, that includes making sure we’re always backwards compatible, even across major versions. While we shoulder more technical debt this way, we’ve found it is better than passing that pain off onto our users and the other developers in our ecosystem. The UI is awesome, but our commitment to BC may be the most understated reason why WordPress has grown to power 20 percent of the web.

One section on that philosophies page actually needs to be updated: in “Striving for Simplicity,” we talk about how we worked to ensure WordPress can be updated in a single click. But in WordPress 3.7, released last month, maintenance and security releases now occur automatically. Zero clicks given! A self-updating web application? Without breaking anything? Yes and yes. The technical challenge was immense, but so was communicating it to our users and developers. If anything ever fails on them, they won’t be inclined to trust us again — whether that’s an update or the simple act of trying to save a post. (That’s also why we focused on stronger autosaves the previous release, WordPress 3.6, which was released only two months prior.)

I’ve gotten a warm welcome so far. Want to talk about development philosophies? How releases are run? How our projects are organized? How decisions and features are made? How to evolve our complicated platforms? Want to chat about lowest common denominators, old versions of PHP, crappy servers, and the crazy things we all see in the wild? Why do we do X? Why on earth don’t we do X? Great. Come find me. I’ll be walking around wearing a WordPress shirt, or you can hail me on Twitter (@nacin).

I have some stickers as well, if you want one.

Menus and credit: It’s called a patch for a reason

Background: You may want to read this post by David Perel, this one by John O’Nolan, and then this one at WP Tavern.

We slated menus for WordPress 3.0 during our developer’s meeting on January 7. After not getting very far over the next month — a lot of that due to our focus on custom post types and the MU merge — we noticed that Woothemes released their system (they did so on January 27). We had been struggling with the concept (early patches used the widgets code as a base) and their take seemed like an interesting angle.

After they contributed a giant patch, we switched the schema over to a custom post type and taxonomy, rewrote a lot of the code to conform to our coding standards, and started to build out an API. After a round of usability testing, we made some numerous design and UI changes. We also needed no-JavaScript support and RTL support, and our new UI called for new JavaScript, so most of everything ended up being rewritten.

Point is, that’s how it works. It’s called iteration. In an open source project, iteration happens very publicly. I can think of a handful of patches I have personally written or committed that ended up getting modified extensively later in the same development cycle, or in some cases outright refactored or removed. This doesn’t make the contributions less valuable. Of the hundreds of patches I have written, many iterated existing code written by others. It’s called a patch for a reason. As we evolved the custom post type system, tons of code got rewritten, some of it dating three years and some of it three days. As we merged in WordPress MU, thousands of lines of code written by Donncha and contributors to MU were in some cases entirely rewritten or simply deprecated and removed. This is how a project evolves, grows, and strengthens.

Menus were a collaborative effort among dozens of developers. The first contribution to the effort, by Jeffikus of Woothemes, was very important. It was a very sizable contribution that then drove our stalled development in the direction we were grasping at for some time. But it was also just the first of hundreds of iterations (like any other major feature) — the patch was an early prototype of a feature we wanted to scale to millions. Like every other individual pouring mind and soul into the WordPress project (more than 200 contributed to WordPress 3.0, dozens on menus), they absolutely deserve credit for their efforts, on top of the respect they have earned for contributing commercial code to the project.

I don’t think anyone is at all disputing that.