It looks as though I may have spoken too soon yesterday. Owen has posted his thoughts on the [dis]continuation of the Philly WordPress Meetup — I probably should have solicited his honest opinions before posting as I did.
I can definitely sympathize with Owen’s concerns — it stinks to be coming in from out at the end of the Main Line for a relatively dismal turnout of people that are looking to talk about something you have little interest in at this point. I like his notion of a BarCamp-esque mega Meetup — it definitely has some potential. However, I see value in pursuing the monthly WP meetups and I certainly would like to see them continue.
I do think that Owen has been one of the most outspoken critics of the WordPress development process thus far and so his “API shifting every 90 days” comment is certainly coming from a position of knowledge. I would temper that comment, though, with some hope. In a recent discussion on the wp-hackers mailing list, a large chunk of code committed by Matt Mullenweg was deemed to be a bad direction for WP to head. He was voted down on the list by the vast majority of users and the other SVN committers, leading to the delay of WP version 2.2 and a stripping of said code from the 2.2 branch of WordPress. An alternative was suggested by Ryan Boren, one that had a great deal of flexibility and future-proofing built in. It was actually pretty amazing to watch in action. Matt has previously gotten a bit of a rap as a unilateralist when it comes to WordPress development. Whether this reputation is deserved is left up to the reader, but the WP community is slowly but surely getting to a good development model. Many of the concerns that Owen and the others associated with Habari have had about WP development are slowly but surely being worked out. Here’s to hoping that the trend continues.
I guess it comes down to this: I’m once again excited about the directions that WordPress is heading and really want to continue meeting with others that will be similarly excited.
Descartes, De Horses And Jumping The Gun
The heyday of the WP meetups I think is at an end, and it doesn’t have as much to do with WP as people maturing with blogging. I think that the meetups are not as helpful to newbies any more because fewer people are coming into the blogging hobby as newbies. As to where more advanced users go, I think that’s where the BarCamp format comes in.
Still, I might head up to New York for their meetups (basically an excuse to visit NYC) and hang out with that gang up there and see what they’re doing with WordPress these days.
A local BarCamp-style meeting is something I’m really interested in. If there is interest in it, it’s definitely something that will happen. It’s just a matter of finding a spot (I was thinking maybe of World Live Cafe?), setting a date, and getting people to come.
I think it’s very funny that you’re excited about the direction of WordPress now that the inspired 90-day development process has stalled “while we polish things up“.
The guy with a fundamental lack of understanding of database efficiency and a disturbing disregard for the people who write the software he profits from (last paragraph reads to me as “if users like it and it’s fast, then who cares what you developers think”) is the one in charge of feature changes and release dates. Don’t consider it prudent decision-making, consider it the uprising of an entire development community, something likely to be required again.
Owen, I would venture to say that my database efficiency knowledge is tempered by running one of the largest websites in the world that has grown more than 10x in the past year and continues to do so on hundreds of servers across 3 datacenters. More people visited WordPress.com today than the entire population of Philidelphia, and viewed about 2.5 pages each. Not to mention Akismet or Ping-O-Matic, both of which handle millions of requests per day in a completely dynamic fashion. You learn a lot in that environment.
The new tags implementation is more flexible but it’s not as fast, which is why we’re looking at ways to cache it by default. I put the original code in to get the ball rolling, and it has. I valued different things in the code than some core folks, and they made their case civilly and intelligently and changed my mind. In the end I want what’s going to be best for WP’s users, whether I wrote the code or not isn’t important to me. It’s not an uncommon thing, this was just more public because it had an impact on the release date, which will still be under our original goal of a 120-day release cycle. (I’m not sure where you got 90 days from.)
A couple of thoughts, if I may.
Matt, I think you may suffer from the same malady that I labor under each day, namely that I try to get my point[s] across in the least number of words possible. I do it primarily to spare my readers from having to sort through a lot of extra verbiage and I tend to view it as a courtesy. However, it often comes across as curt, dismissive and even disrespectful simply because of the fact that written communications in the digital age simply lack any ability to carry tone or intent without the author setting them out in broad strokes. It’s unfortunate, but it’s a reality.
Owen, I do think it’s a bit unfair to hold Matt to the argumentative standards that you would seem to in your comment. I recall the X/HTML and database normalization/tags discussions on the Habari dev group as getting quite heated with each side pushing for their interpretation of specs and best practices. Right or wrong, Matt definitely took his lumps on tagging for WP.
I guess I was trying to say that my hope and faith in the WP developer community and process has been restored a bit. I was definitely getting a bit down on the whole model around the whole merging-the-bookmark-and-post-categories timeframe. The development models of Habari and WP are fundamentally different, and that’s okay. I’ve dipped my toes into the Habari pool a bit and have found that I’m more comfortable hanging with WP. It’s what I’m used to, it’s what is comfortable and it’s GPL’d. Didn’t mean to spark anything.
Sorry if my comment came across that way.
Matt:
‘Twas more of a generalized observation than a particular critique of your comment. Please don’t take it as an insult.
Busy people write short emails. Really busy Congressional staffers use Blackberries. People that want to seem busy do both.
*grin*
Matt, the size of WordPress.com’s database is just one more reason why it would be better if made more efficient. Do you claim that the argued tag implementation would have done that job? I haven’t heard that claim from any side, and I don’t believe it’s true.
I don’t understand how you illustrate that any efficiency design has been targeted at the WordPress database model by diverting the discussion to WordPress.com, where you’ve simply thrown extra servers at the problem. Clearly, you’ve not learned enough from the complex task of running wp.com to approach such a simple problem as the WordPress database schema, which only seems to have changed for the worse over the last few iterations.
As far as the actual implementation – the circumstances expose the failings of WordPress management: The failure to gauge community reaction to a new feature (or did I miss “combine the tables” as a request on the Ideas page?). The failure to discuss radical change in implementation with affected developers before committing it. The failure to respond appropriately to unilateral push-back. You describe the circumstances of the delay of WordPress 2.2 like it was a casual event that happens every day — I suggest you re-read the thread.
Doug, in regard to the X/HTML debate in Habari, you are exactly right. Both sides got their say before anything was decided on, and the details leading to the final decision were explained to the community openly before they were affected. Whether there was a single week left or five, the discussion on the table/tags issue for WordPress only took place in the community after the change was already committed with little time left for debate before release. Not everyone reads every comment on Trac; it’s not an adequate discussion forum.
The recanting of the offending code was a result of Matt ultimately making the decision himself, over which he could just as easily have decided the other way – something that can’t happen with Habari since no single person holds that ultimate power.
If you’re more comfortable with WordPress and GPL, that’s fine. But you need to keep your eyes open when you jump in the pool. Maybe you haven’t noticed the creatures that lurk beneath WordPress’ cool and inviting surface.
“Do you claim that the argued tag implementation would have done that job?”
I’m not sure what you’re referring to, but the original tags implementation was basically zero overhead from a front-end query point of view. However the terms implementation incorporates everything I really cared about and it can be made just as fast with the postmeta suggestion from Mark.
“Clearly, you’ve not learned enough from the complex task of running wp.com to approach such a simple problem as the WordPress database schema, which only seems to have changed for the worse over the last few iterations.”
I’m very happy with where the schema has gone in the past few iterations, for example Domas’ reviews and changes that went into 2.1. And now we test these changes in a production environment which does tens of thousands of queries per second, something not many software projects can claim. We know what works and what doesn’t based on facts, not conjecture.
In fact I’m at the MySQL conference in Santa Clara right now and have discussed the current system and proposed changes with several developers and performance experts here. I’m not sure what basis you have for continually attacking my DB experience or WP’s schema, and it’s a little insulting to the entire team that you’re attacking our design without facts to back it up. I’m far from perfect and have made plenty of mistakes, but I think collectively what we generate is pretty nifty. Anyway the proof is in the pudding. You’ve got your own blog software now where you can prove your point and do things “right,” so build something better and make it popular.
Combining all of the various “tag-like” tables into a single table is the antithesis of good database design. There is a reason why separate tables are used in databases, and why WordPress database design leans toward defying that reasoning eludes me.
The changes you speak of were mostly index changes, and weren’t comparable to the changes discussed recently, for which – even in the light of having tens of thousands of queries per second of testing – there are no public efficiency results compared to a conventional multi-table database design available. It makes no sense to say simply “it’s pretty fast” when there is no comparison being made; the total number of queries handled is irrelevant without comparison. Making changes based on testing would certainly be more convincing. Show those comparison results, and I’ll take changes to the database design seriously.
You’ve discussed the system and proposed changes with developers and performance experts at the MySQL conference, so what were their conclusions? Who has said that the WordPress schema is the efficient machine that you imply? I wonder why, in the thread I previously linked, the rest of the WordPress development team disagreed with the changes you summarily imposed upon the entire community.
You’re right saying that the proof is in the pudding. In tests I have seen, Habari offered consistently faster database access for comparable features offered by WordPress, and we haven’t even started optimization for speed yet. Popularity isn’t really a gauge of performance or effectiveness, is it?
But this comment thread we’ve hijacked ungraciously on Doug’s site (sorry, Doug) wasn’t about your database knowledge, because I trust that to other people for Habari, too. It was more about the management style of the WordPress project, and the routine snap decisions on code changes without first surveying the community that’s affected – including the livelihood of many of them. Without question that problem is solved in Habari.
The implementation was discussed for several months on Trac, but frankly it wasn’t going anywhere. Sometimes reasonable people can disagree, and it’s better just to get some working code so you have more a concrete base to work from. I didn’t impose anything, I just committed code to an unstable trunk. Both Ryan and Mark supported the original idea, but after we started noodling with it and working out the bugs it became obvious that a lot of things sucked about it, and no one (even people whose checks I sign) was shy about expressing their opinion.
The important thing is that the currently proposed solution is better than BOTH my original idea and the tags table patches in the ticket, it’s something else that we weren’t able to imagine before we had working code in front of us, even if that working code only served to tell us something that didn’t work. Knowing what not to do is just as important, and I’m a strong believer in failing fast and iterating.
I don’t think anyone involved took it personally, including people like myself whose “livelihood” is WordPress. My only regret is that it should have happened at least a month or two earlier in the dev cycle. The new release cycle is an experiment and we’re learning along the way. The real test will be 2.3, and I can’t wait to get started. 🙂