The plugin creates a custom post type (Rideshares) which enables you and your community to get to where you want to go using less gas and having more fun on road trips. It has been designed towards event-based rideshares in particular so that drivers and passengers in the same city can co-ordinate their travel to whatever festival, concert, workshop, WordCamp, etc they are attending elsewhere. The admin form is easy for adding / editing rideshares for those who have access to your sites’ admin console. To make the process as easy for your extended community, this plugin also provides an exceptional Gravity Form to let anyone submit their rideshare request via the front-end of your website.

For more details I’d point you to either check out the plugin repository with it’s detailed installation instructions or the rideshare.idealienstudios.com plugin site that I setup to support it.

In case you’re wondering why v0.1, it’s because the plugin doesn’t (yet) have all the features / functionality in it that I think are worthy of a 1.0. At the moment, I’m expecting to do a big version jump when:

• The Gravity Form is added to an installation during initial plugin activation.
• You can configure the plugin via an options screen to operate in a straight date-based model or the event-based one it has initially been designed for.
• Uninstalling the plugin will remove all taxonomy and custom post rideshares.
• Registered users gain the able to remove their rideshare request when you have filled it.
• Cron job added to remove any rideshares that have expired

Single Site Instructions

The MT: GS single site migration documentation for is quite excellent. My process was only marginally different than what they describe. A brief outline of the process which took 10 – 20 minutes per domain depending on file sizes:

1. Add a new domain on MT:GS
2. Create email user with FTP and SSH access for the domain.
3. Create new database and user / pass with permissions access to it.
4. Login to your phpmyadmin to take an export of your entire database.
   Optional: Use a WordPress database backup plugin if you find it easier.
5. SSH login to your existing webhosting domain root folder (httpdocs? html? wwwroot?)
6. tar -zcf yourentiresitebackup.tar.gz *to create a single archive of your entire site.
7. SSH login to your MT:GS server and the appropriate domain /html/ folder.
8. wget http://[insertyourdomainname.com]/yourentiresitebackup.tar.gz to copy the archive folder.
   For large sites or for those who are not on truly high-speed connections, doing this server-to-server copy of a single file is MUCH faster than the alternative download to local PC / upload to new server alternative.
9. tar -zxf yourentiresitebackup.tar.gz to uncompress the archive.
   Don’t forget to delete the archive once you’ve confirmed the site is operational.
10. Go into the MT:GS database admin page and import your mySQL archive from step 3.
11. Setup your new local FTP connection in your development IDE of choice.
12. Your database connection strings will have changed. Modify the wp-config.php files on the new server.
    The tutorial linked above outlines this information very well. The change of localhost to $ENV{‘DATABASE_SERVER’} was the only unexpected item to me for this.
13. Replacing 000000 with your account details, you can now preview the domain either at http:/s00000.gridserver.com if it is the primary domain on your MT:GS site or http://sub.alt-example.com.s00000.gridserver.com if it is an additional domain.
14. Update the DNS entries and wait for the magic to happen.

Their tutorial did cover updating site paths & previews within the SQL database before updating the DNS, but once you’ve ensured your landing page is accessible, the rest of the site will show properly when the DNS have propogated so I found it as a step worth skipping. You may have to re-generate your .htaccess file via the WordPress admin console once that has been done. If you’re DNS are taking longer than you care to wait you can temporarily map DNS/IP addresses to the new server.

Another quirk I discovered is regarding the mail server configuration. Despite the fact that, “When a domain is added to a (gs)Grid-Service, the mail service is automatically created” it is not enabled by default. You have to enable it via the account center in Media Temple.

MultiSite Migration

Wash, rise, repeat? Almost. In the case where I was migrating existing domains as a part of a MultiSite installation things were essentially the same for steps 1 to 13 as above for the primary domain.  In the case of the sub-sites there is no need for database or file transfer since the primary one stores everything. One merely had to create a symlink between your subsite and primary network site via ssh on your MT:GS environment. This was actually a lot easier to resolve than my previous hosting environment which had a mix of cPanel + Plesk and required an intricate series of steps.

To bring other domains over to the new WordPress Network on MT:GS environment this migration guide was a useful place to start. A couple of other pieces of info I discovered along the way that may prove helpful to others:

• The WordPress Import screen for WXR data will not be available on sub-sites until you enable it on the primary domain of your Network.
• With the Super Admin / Network Admin changeover, as of 3.2.1 you may find the excellent domain mapping plugin menu has changed locations.
• When dealing with a site that was already domain mapped in the new installation (but had not yet had the DNS updates) I was struggling to find a way to preview the site similar to step #13 above for a single site. The subsite URL would re-point to the full domain, and the subsite.s000000.gridserver.com would be treated as if it were a new registration request. The easiest solution is actually to NOT have a domain mapping in the primary site until you are ready for the switch, that way subdomain.primarydomain.com will display everything as you need to test plugins, theme, etc.
• The WXR import / export will bring all your posts, pages and related content and then offer you the option to bring across all attachments which could be a lengthy conversion depending on size of your files – which are essentially moving from /wp-content/uploads/ on your single-site to /wp-content/blogs.dir/##/ on the new server where ## represents the ID of your subsite.
• Don’t forget to confirm whether the plugins / theme features from your single install work on the multi-site environment.

Good luck! If you find any other tips / tricks that can help others on this path, feel free to post a comment to share.

The GPL website FAQ does mostly addresses this concept, “If the program dynamically links plug-ins, and they make function calls to each other and share data structures, we believe they form a single program, which must be treated as an extension of both the main program and the plug-ins.”

Bryan at One Man’s Goal pondered the issues surrounding digital copyright leeching and the following quotes summarize the (then) prevaling opinions on this situation:

By designing on a GPL platform…when you release it to the public you are releasing it licensed to everyone not just those who pay for it. Companies like Redhat linux make their money not by charging for the linux o/s which is open source, but by charing for support and tweaking packages that are added to it. That’s why CentOS can directly clone what Redhat Enterprise is and not be touched.

The part of themes or plugins which makes them subject to the terms of the GPL is that they use WordPress code hooks to extract data from the WordPress database. While theme designers can SAY that their theme is licensed under some non-GPL model, they have no legal basis to do so. Someone profiting from reselling the work of another is ethically rotten, but in the current legal landscape is technically fair.

This issue of theme theft, re-selling (or conflicting business models and the GPL) comes up every couple months. This obviously sucks, but based on the current WordPress code structure and theme distribution model, there isn’t a lot which can be done – it is the nature of the beneficial beast that is working with open source licensing models. It caused me to think outside the box and ponder a different approach to resolve the problem at hand.

Distribute separate theme packages with split license

1. GPL-licensed files which include all references to WordPress logic
   This .zip archive would only contain the .php files which make up the theme – sidebar, header, index, comments, etc. These files would only have integration to css through the id / class names applied to div containers. A blog owner that deploys this package alone will have their content displayed in a reasonable approximation of the theme structure without any styles applied.
2. Images, javascript and css files licensed under whatever terms the designer wishes
   This second .zip file would contain all the elements required to convert that basic structure into the beautiful presentation shown in the theme screenshot / demo. After purchasing this set of files, the user would have to upload these into the theme directory – a process which has been proven simple enough for most blog owners to execute without issue.

What are the benefits?

• Separate downloads equals separate licenses
  This concept would be viable because of the difference the GPL affords non-dynamically linked plugins. As the visual elements could be used with any system they would not be subject to the terms of the GPL.
• Separating form from function
  Decoupling the business logic and presentation layer is a best practice which simplifies future development efforts. Developers already recognize the benefit of separating substance and style – html and css anyone? Automattic made a sound decision to separate blog operations (wp-admin) from custom functionality (plugins) and presentation (themes).
• Consistent with standard design processes
  Designers usually cut a photoshop file up into images and use a static .html template file to perfect the css with them. The non-gpl .zip file would represent this stage of design. The PHP code which uses WordPress hooks to dynamicize this template would become the GPL-licensed .zip file in effect.
• Developing architecture agnostic solutions
  With the graphics and css separated from WordPress specific code, your theme is now portable to other open source architectures: Joomla, Drupal or Expression Engine. Whether the premium designer does the work themselves or partners with someone else, they have diversified their potential markets. Including the static .html file(s) you built during the design phase and it could be sold as a generic css template as well.
• Multiple premium themes from one template
  If the css elements are well-designed it would be easy to create multiple themes from the same template. A fishing blog and could buy incremental series of graphics for ice fishing, fly fishing or bass fishing, or a seasonal treatment to a single outdoor painted scene.

I would suggest that the designers be nice, and implement a basic styles.css with the GPL code. Give the user a rough guideline based on sizes of the placeholders for where the graphics would go. Include a link in the comments at the top – which show up in the WordPress theme page – where they can / should download the graphics if they want the full effect of the premium design.

What are the problems?

• A challenge for premium theme galleries?
  The dozens of free WordPress theme galleries would not require any change, but any premium theme galleries would. One might argue that since they already have a different download process with credit card collection – it’s not like there is a high degree of learned behaviour to overcome so this isn’t that much of a problem.
• Asking users to do more in order to implement a design
  The majority of blog owners seem comfortable with the process of downloading to PC, unzipping into the wp-content/themes/ directory, uploading to server and activating, so adding a second download/unzip/upload is another non-issue of sorts I suspect. If this idea takes hold and all premium theme developers begin to adopt this process, eventually users learn that is the expected set of actions required to install a premium theme.
• A thief is a thief is a thief!
  Not much you can do about someone who has no moral issue with theft. Yet this con becomes a pro by the fact that you now have a legal recourse to sue Mr. Thiefy McStealerton as your original artistic works are not subject to the GPL but to the license you chose to make them available for purchase under.

I could only come up with one other option, which was to suggest that designers host the css / graphic files on their own servers and restrict who has access to them. Obviously this puts an external dependancy on blog performance which many would not like, but would give a more significant level of control as the styles.css file and images would be on your server. Perhaps this concept would work for WordPress.com users and the marketplace concept which Automattic has been hinted is coming in the near future.

In the 2 years since I originally wrote that article, the premium theme industry developed around a number of thriving businesses. Today, most of the theme developers who sell their wares do so entirely under the GPL. The symptoms causing the questions to be raised may have changed, but the important ones still remain:

1. Can (or will) developers distribute their work under multiple licenses which would respect the source code base license?
2. What do you do if someone does not respect the license that your product is distributed under?
3. How will this on-going conversation affect the open-source community surrounding WordPress?

Rideshare Custom Fields captured via More Fields

As I mentioned at the end of my last post on the Power of Custom Fields, I recently started working on a prototype site that required rideshare board functionality. Storing the details lends itself well to custom fields, especially when More Fields is used for data capture as you can see from the inset image. However, I struggled to find a solution within WordPress to solve a display challenge: How to display a set of posts based on multiple custom field values? In my case, how to loop through rideshares base on event and ride-givers or ride-wanters.

I explored looping through each post in my rideshare category to match the rideshare event to an array value and then using get_post_meta within to see if results belonged to the ride-giver or ride-wanter. While this might have worked, it certainly wouldn’t be an elegant – or Idealien solution. Dan Butcher did provide a functional solution in the WordPress Support Forums for a similar challenge, but it is not a solution a novice / intermediate WordPress developer would be comfortable customizing, nor would it scale well. Barry @ clearskys.net informed me that,

Whilst the JOINS work, and will work quite well with a few meta-data criteria passed in, I’ve had problems (particularly on shared hosting) in the past when creating an SQL query to search based on a series of tags which used a similar method.

Introducing get_post_meta_multiple

This function I created, with sql optomization support from Barry @ clearskys.net:

• accepts a variable length array of custom field key/value pairs
• returns a list of post IDs which you can loop through
• Could be implemented into your site in one of 3 ways: Added to a functions.php file as a part of your theme, included in a plugin related to enhanced custom field functionality or report a (feature request) bug for a more evolved version of it be included in a future release of the core of WordPress.

The demonstration code below has been prepared for the most common scenario as part of a functions.php file in a theme.

The Demonstration

A series of tables with columns for number of seats available, departure / return dates plus contact / additional info. I have kept the code below intentionally short so the example doesn’t overwhelm. I have posted a more complete version on pastebin that has the markup to match the image above.

The function

function get_post_meta_multiple($metaDataList) {
	global $wpdb;
 
	$querystr = "SELECT p.* FROM $wpdb->posts AS p WHERE p.ID IN ( ";
 
	$querystr .= "SELECT post_id FROM $wpdb->postmeta WHERE ";
	$innerqry = array();
	foreach($metaDataList as $key => $value) {
		$innerqry[] = $wpdb->prepare( "(meta_key = %s AND meta_value = %s)", $key, $value );	
	}
 
	$querystr .= implode(" OR ", $innerqry);
 
	$querystr .= " GROUP BY post_id ";
	$querystr .= "HAVING count(*) = " . count($metaDataList);
 
	$querystr .= ") AND p.post_status = 'publish' ";
 
	$metaResults = $wpdb->get_results($querystr, OBJECT);					
	return $metaResults;
}

Example Usage

Place this inside your category.php or whatever template file you are using to display the results from.

<?php //Create your array of custom field key / values to filter to
	$metaDataList = array(
	'rideshare_event'	=> 'Ottawa Blues Fest',
	'rideshare_type'	=> 'Driver'); 
 
	$resultList = get_post_meta_multiple($metaDataList);
 
	if ($resultList):
	//Loop through each result post to display appropriate contents
	foreach ($resultList as $post):
		setup_postdata($post);
 
		// Define your custom field key
		$key="rideshare_spaces";
 
		// Display value of custom field		
		echo get_post_meta($post->ID, $key, true);
 
   	endforeach;
	else : ?>
		<p><?php _e('No rides are currently available for this event.'); ?></p>
	<?php endif; ?>

The future of the function?

Once I have finished the prototype site that started this concept, I will attempt to package up the pieces in a more manageable method to share for wider use. In the interim, feel free to use and share in whatever ways are most convenience for you. Much like WordPress as a whole, I think this idea can continue to evolve in some great ways that will make it easier for designers, developers and clients to build / use sites based on it. Please link back to this post as you do so that I can keep tabs on how this idea evolves.

Learn to love get_post_meta

The get_post_meta function is a function you will come to know and love when working with custom fields in WordPress. It is used within the loop to present the value based on the name of the custom field.

<?php $key="rideshare_name";
echo get_post_meta($post->ID, $key, true);
?>

Beyond the basics

If you are doing more than just basic data storage / display with custom fields, the following links / examples will be of interest to you:

• Web Designer Notebook covers how to display multiple values for the same custom field name. This might be useful to display a list of ingredients for a recipe site or the parts needed for a set of DIY instructions.
• Tutorial9 has a great tutorial on the many different ways to use custom fields for storing images to represent a post. After uploading the photo, you store the filename of a full-size or thumbnail photo in a custom field and use get_post_meta to extract / display in the appropriate theme file locations.
• Cagintranet has 3 custom field tricks that operate per post: custom read more tags, thumbnails of related posts and post-specific css overrides.
• LiveXP shows how to get custom fields outside the loop. If creating a theme options page is beyond your skill, you can create a private page and store / retrieve the meta values from custom fields attached to that page wherever you need to.
• Two Words: More Fields. This plugin enables you to create custom write panels with custom field data types (radio buttons, drop-down, textbox, wysiwyg, etc). My most recent screencast gives a good overview of using More Fields to design a store location list using the plugin.
• Sidetrack Suggestion: I can easily see (and hope that) the type of functionality More Fields has explored gets built into the core as a part of the post-types being considered for 3.0. With the drag-drop interface of the widgets management area applied to the design of write panels, this would be a fantastic feature of a future version of WordPress.
• Justin Tadlock has written immensely on the power of custom fields. If you want a crash course in custom fields, his site is a great place to start.
• Smashing Magazine shows how to get posts with a specific custom field and specific value as one of their 10 useful WordPress Loop hacks. This is invaluable when capturing data that you want to filter for in query loops.

What actually inspired me to write this post was my recent efforts to build an elegant solution to a query quandry I was having related to custom fields – How to filter / query for multiple custom field key / values? The solution is one that could be of interest to theme / framework designers, plugin developers or possibly even the base concept for implementation into the core of advanced custom field functions WordPress.

If you have any other great custom field tutorials, please share them in the comments of this post.

Capture and display custom data types using ICE and More Fields

Building on the concept of category templates which I started with the FAQ template tutorial last week, this tutorial will cover how to capture and display custom fields in a template. What’s more, I’ll go through the step-by-step process of how to implement this using More Fields which is a plugin that “enables you to define post types, which are custom Write/Edit pages that contains a pre-defined set of boxes” that store their data behind the scenes in custom fields. The concepts from this tutorial will be of interest for anyone who:

• Has multiple categories of blog content with unique data to capture / present. Thumbnail per post, photo of the day or other customized items.
• Uses WordPress as a CMS for unique page data types (event calendar, classified ads, business partners, etc)
• Finds the selection of custom fields from a drop-down to not be the best user interface experience for capturing structured data.

Direct Video Link:http://www.screencast.com/t/2dcpYsSlk

Example Code

The only real code in this template that is unique is the retrieval of data from a custom field using the get_post_meta function.

A single custom field retrieval
Place this example within the loop of an existing category / post template.

<?php $locationPhone = get_post_meta($post->ID, 'locationPhone', true);
if ($locationPhone != '') { ?>
	<div class="locationInfo">
		<h4>Phone Number</h4>
		<?php echo  $locationPhone; ?>
	</div>
<?php } ?>

Full retail location fields
This example is the full loop for use within a category.php file to display the contents of custom fields named: location

<?php if (have_posts()) : ?>
	<?php while (have_posts()) : the_post(); ?>
 
	<h2><?php echo the_title('','',false); ?></h2>
	<?php the_content(); ?>
	<div class="clear"></div>
 
	<?php $locationAddress = get_post_meta($post->ID, 'locationAddress', true);
	if ($locationAddress != '') { ?>
		<div class="locationInfo">
			<h4>Address</h4>
			<?php $locationMapURL = get_post_meta($post->ID, 'locationMapURL', true); ?>
 
			<?php if ($locationMapURL != '') {
				echo  "<a href='" . $locationMapURL . "'>"; ?>
			<?php } ?>
 
			<?php echo  $locationAddress; ?>
 
			<?php if ($locationMapURL != '') {
				echo "</a>";
			} ?>
		</div>
	<?php } ?>
 
 
	<?php $locationPhone = get_post_meta($post->ID, 'locationPhone', true);
	if ($locationPhone != '') { ?>
		<div class="locationInfo">
			<h4>Phone Number</h4>
			<?php echo  $locationPhone; ?>
		</div>
	<?php } ?>
 
	<div class="clear"></div>
 
	<?php $locationHours = get_post_meta($post->ID, 'locationHours', true);
	if ($locationHours != '') { ?>
		<div class="locationInfo">
			<h4>Business Hours</h4>
			<?php echo  $locationHours; ?>
		</div>
	<?php } ?>
 
	<?php $locationWebsite = get_post_meta($post->ID, 'locationWebsite', true);
	if ($locationWebsite != '') { ?>
		<div class="locationInfo">
			<h4>Website</h4>
			<?php echo  "<a href='" . $locationWebsite . "'>" . $locationWebsite . "</a>"; ?>
		</div>
	<?php } ?>
 
	<div class="clear"></div>
 
	<?php endwhile;
 
else : ?>
 
	<p><?php _e('Sorry, no posts matched your criteria.'); ?></p>
 
<?php endif; ?>

Tuesday July 7th, 2009 will be the first Ottawa WordPress Developers Pub Night. Location and time are subject to interest from the community. Current theory is a start time of 8pm at Shoeless Joe’s at 3049 Carling Ave which has cheap wing night on Tues and very nice booths.

The two best ways to let them know you’re interested in attending are either post a comment on their blog or follow and tweet to them on Twitter – @wdgo. I know there are more than a few people in Ottawa who use WordPress for great things including myself. I look forward to meeting them for a few pints to talk about what we would all like to give / get from a community developer group for our platform of choice.

In the introduction of WordPress.tv, they suggested that “now you can shape what comes next” by offering suggestions of what we would like to see on the site. The following list are a few of my suggestions:

Channels dedicated to release notes / details

A series of channels dedicated to covering the significant fixes / upgrades that occur in each release of WordPress. One could focus on the changes from a user perspective, although those have generally been well-covered by the blog-o-sphere in print. Documentation is usually the last thing to happen on projects (and gets short-changed as a result) it has the biggest impact on the ability for others to use / enhance the system.

I would like to see a series of videos dedicated to giving developers who use WordPress but aren’t involved in committing code to the core, a more in-depth understanding of what has happened behind the scenes to make the changes happen. A few examples from my own experience:

• The 2.7 release overhauled how admin menus are loaded which had the potential to affect how every single plugin was integrated. A video on the new different options would be been incredibly useful.
• The same goes for creating menus using the new table-less standards which were noticeably short on documentation at launch.
• See my previous twitter rant about the lack of details on Administrative Hooks that were added / removed. Putting //TODO into public facing documentation is not cool.

Insight into Automattic

From conversations with Jane and Matt during my most recent Wordcamp, it sounds like the folks at Automattic have some lively discussions about the approach to implementing new / enhanced features. Perhaps record one weekly meeting to give developers a chance to see this process in action. This could be expanded to be a web-based conference call for those who have access / interest in contributing code to the core and the results posted online. You might consider this a request to open the source of the development process

Strongbad Matt

For those few souls who haven’t discovered Strongbad, you could take the boring Wikipedia approach to learning about this episodic web cartoon or enjoy a half-hour of humour at Homestarrunner.com (personal faves are virus and techno). Each email answered results in a random series of adventures. Given his travel schedule, this could be a great way to see some of the more entertaining behind the scenes of the defacto public face of WordPress.

If you have more suggestions, either add them in the comments here or submit via the WordPress.tv contact form.

I first heard about the WordPress theme repository submission guideline changes through a post on the topic at XFEP.com in which David Peralty pontificates that:

Matt blames theme creators for not thinking creatively when it comes to building a business around theme development, but if he keeps cutting off their arms when they try to find ways to build a business, eventually, they will give up and move on to something that gives them a better return on investment regarding their time.

As I summarized in my last post, the actions Matt has taken only affect the WordPress.org site – one destination amongst the vastness of the Internet. The actions are based on their open source roots and approach to the GPL which it is licensed under. Giving away free themes that are primarily created to be an upsell engagement is completely fine, but it won’t be something that gets promoted on WordPress.org. In the same way that they won’t support those businesses / business models which prevent you from redistributing or using their product on multiple sites.

WordPress is something that is going to be around for decades – 5, 10, 20 years from now. So the decisions that we make now are going to influence which direction it goes. You can look to other open source projects to how this happens. What is going to keep WordPress from becoming a post-nuke, or even like a Joomla? Where you go to it and it seems like most of the stuff is paid and there aren’t that many free resources. Ultimately this is going to hurt the viability of the underlying platform. I think it’s really a commitment to what got us to where we are today…..I think that would ultimately kill the project. We need to be true to what got us to this point in order to stay around and stay relevant.

The business of open source

So really, theme developers need only ask themselves whether they believe in open source and wish to support and benefit from it or work with a closed source / proprietary operation. Matt touched on this during the WordPress Weekly discussion in context of proprietary themes with Joomla, “Joomla has said anything goes and it seems to be the situation that premium themes are really crowding out the free resources. Which kind of makes sense if you align the economic incentives where you’re actually disincentivizing anyone to make open source stuff, eventually what’s going to happen is over-time the community will be more and more commercial.”

Over the long-term proprietary business models that seek to create demand by exclusivity are doomed to failure when competing against the shared resource model of open source. If you look at the largest and most influential software companies of the world you see integration with open source on some level. Early adopters like Unix and IBM gave heaps of foundation code to Linux and Eclipse respectively. Other companies have seen this shift and are adapting their existing business models to the new reality.  Adobe has released parts or all of their development frameworks to the community, although I don’t see them doing this for Photoshop to Gimp any time soon. Even Microsoft is slowly shifting towards a software-as-a-service  business model which can contribute and benefit from open source. They all realize that with the development technologies available to the world today, anyone can build a competitive product that offers 80 – 90% of the functionality. Each in their own way have wisely chosen to be a part of the solution rather than a competitor.

Why do you believe in open source?

David also made a bold statement that “Theme developers and plugin developers only believe in open source when they can make a business from it.” while true, is a highly flawed argument. I have made a successful business using open source products but my prices are based on the services I provide, not the products I use. Any overhead of product licenses incurred would be passed directly on to the customer. I believe in open source because it is the right thing to do:

• The majority of websites developed by Idealien Studios are built using open source software such as WordPress, PHP and mySQL. In each of these cases I can justify how a particular open-source tool is as good or better than a proprietary alternative.
• I am fully knowledgeable / capable of working with other closed source platforms. Yet in the absense of a direct requirement by a client to use a closed source technologies, my preference is open source.
• I believe in open source for the same reasons that I believe in the value of a public education system. Sharing knowledge, information and opportunity with anyone who wants it is the right thing to do.
• As much as I build websites for people, I strive to build tools and technologies that enable my clients to be self-sufficient. This probably has something to do with my upbringing with two parents for teachers and a desire interact with people who can get more from working with me than just the end product. After all, life is not about the destination but the journey.

Why is WordPress wonderful?

I think WordPress has built a perfect balance between capitalistic goals and social obligations. The .com site is an implementation of the open source tools that the .org provides for free to the world. There are other tools starting to come to market (DimDim, Screencast.com / Jing) emulating this model.

WordPress has shown – both in the past with the plugin repository and now again with this new theme repository – what their stance is on open source and that they are willing to reward those who share their vision by prominant placement on WP.org which can result in a significant amount of traffic. The best analogy that Matt made during the conversation on WordPress Weekly was to compare this situation to ones that Google encounters with people getting bent out of shape about changes their algorithms (in response to the very same people trying to “game” the system). Neither Google nor WordPress is stopping you from doing anything you want with your own site or sites you build or maintain for clients. Both of them are saying that if you want to be supported by them or get a share of the significant amount of eyeballs that can come from their respective sites, you’ll have to agree to play by their rules.

In order to shed some light on the details involved in the situation, Matt spent over two hours yesterday on a special edition of WordPress Weekly to answer any and all questions put forth by the community. If you have the time to listen to it the entire conversation it is worthwhile (accessible in the embedded audio player to the right). A good deal of the discussion could be applied to any open-soure project.

I started to transcribe a few of the questions / responses that I felt were noteworthy and ended up with 4+ pages of notes. Rather than create a Neal Stephenson-esque post, I’m going to break it down into several pieces over posts in the days ahead.

Do you get what you pay for?

The question was asked, “Have premium themes furthered the development of themes as a whole?” and Matt made note of the fact that premium implies it is inherrently better than the alternatives. This is not necessarily the case, especially over the long-term. When you begin to look at the restrictions that are written into most of these purchase agreements, they restrict what you can / cannot do with the theme you purchased. His preference would be to use the term proprietary themes as it is a more accurate representation of the non-GPL licensing restrictions. The GPL always has been about protecting the freedoms of end users, not preventing developers from making a profit. Matt quoted the four fundamental guidelines in context of this conversation:

1. The Freedom to run the program for any purpose.
2. The freedom to study how the program works and adapt it to your needs.
   Access to the source code is a pre-condition for this.
3. Freedom to redistribute copies so you can help your neighbour.
4. Freedom to improve the program, release your modified versions in general to the public.

The third and fourth elements are particularily damaging given the themes are derivitive works from WordPress. The litmus test for this is to ask whether something will run without the original work and a theme would certainly not display the content from a database without all of the WordPress functions. Matt drew on the contrasting examples from a developer perspective of the “premium magazine themes” versus Kubrick which is the default theme for WordPress installations.

If I want to build on top of a cool magazine theme is, I have to basically start from scratch and in fact be very careful not to be too close to what I’m trying to emulate. Compare that to some of the free themes that have rocked the WordPress world in their time. Including the one we all know and love now, Kubrick. Instantly on top of Kubrick there are a bunch of things that people just start copying and pasting the code and tweak it and make it better. You have this really fast innovation.

I don’t know if any of you guys remember the very first Kubrick versus what we eventually put into WordPress; it changed significantly. What happend was an open source community developed around it and started tweaking the design, the code, everything like that. I think that is sort of a good example, and there have been many others since then, of where you really get the benefits of open source. Both in the quality, the users and the developers benefit because the developers get people helping him out making it easier and better. The users get this rapid innovation and a lot of themes based around the things they like.

What I believe has been missed in the current controversy surrounding theme removal from the WordPress.org site is that these actions were all taken with the same overall guideline in order to stay true to the root concept / philosophy of open-source that WordPress came from. Everyone is free to do what they want with the software, including creating a fork version of their own if they truly disagree that the approach Automattic has taken the platform. Just the same way as they would be able to compete with WordPress.com by launching their own WordPress MU installation. All Matt has suggested is that, “Ultimately it’s about freedom. Not talking about whether it is illegal or not to do these things. All I’m talking about is WordPress.org, the site we run and host, do we want this stuff in there and that’s all I’ll really speak of authoritatively.”

In the coming days I intend to take this discussion towards more extended concepts surrounding WordPress including:

• How a theme designer can structure their files to fit the theme gallery approval requirements.
• What business models based around WordPress Matt believes are viable
• How much community involvement exists with the development process of WordPress.org
• Matt Mullenweg’s true conspiracy theory which I am in complete support of!