# | Visit Site »

At Crowd Favorite we work primarily with WordPress, but also with many other Open Source projects. We are often working with larger companies that have standard Master Services Agreements (MSAs) or Professional Services Agreements (PSAs). These agreement templates are designed so that these companies have a known legal foundation to work from, and include a variety of requirements and terms that apply to the consultants working for them and governing the Deliverables created by those consultants. These agreements often have standard language in them that have some interesting side-effects when you are working with Open Source.

It’s common for services agreements to have these components:

1. Deliverable
2. Warranty
3. Indemnification

with a set of terms around each. The standard terms in these agreements likely contain language that may be somewhat problematic when applied to projects built on Open Source.

Deliverable

Let’s look at the Deliverable first. In a standard web site build the deliverable might be loosely defined in this manner:

A custom web site powered by WordPress, using existing and custom created plugins and themes to achieve custom functionality. Consultant will deliver the entire package along with documentation and installation instructions, and will assist with the initial installation and configuration of the site.

The Deliverable described above has five potential parts: WordPress, existing plugin(s), custom plugin(s), existing theme(s), custom theme(s). The Deliverable is generally what the Warranty and Indemnification clause are tied to, so the way it’s defined is important.

Of these five parts, you will probably only have created the custom plugins and custom themes from scratch. The others will be created and licensed by other companies and/or individuals. You do not want to take on full responsibility for these parts of the deliverable in the Warranty and Indemnification clauses.

Warranty

The Warranty part of the contract generally has two parts: terms that cover how bugs will be fixed and for how long; and terms that declare that all of the intellectual property (IP) in the Deliverable is free and clear of infringement.

I’m assuming that you don’t want to be on the hook for every bug that might exist in WordPress (or whatever other Open Source package you are working with), so you need to make sure you get the language here adjusted so that it reflects this. You’ll probably end up in some middle ground on this, as your client will just want the solution you’re building for them to work, but you need to limit what you are willing to take on.

It’s the second part of the Warranty that is particularly dangerous. While you may take on some responsibility for fixing bugs in the overall deliverable, you definitely don’t want to take on responsibility for all of the IP in any Open Source project. If you do this, and it turns out someone in another country committed code that wasn’t legal for them to commit, you’ve just taken on responsibility for that.

We typically resolve this with a “to our knowledge” clause, which covers the client for code we create, but absolves us of responsibility from other Open Source code (assuming we are using code that was properly licensed, etc.). It also covers us in the event we are asked to build something that infringes on an existing patent.

If you breach one or more of the Warranties, then the Indemnification clause comes into play.

Indemnification

Indemnification ties in with the same issues discussed in the Warranty section. In this clause, there is typically language that makes you (the consultant) responsible for any legal issues with the Deliverable (instead of the client, who is using the Deliverable). Like the Warranty clause, the Indemnification clause is a fair and reasonable thing to have in a contract. We just need to tweak it a little so that it makes sense in the Open Source world.

It’s very reasonable to take on this responsibility in regards to any part of the deliverable you build, subcontract out, or are somehow responsible for. However, like with the Warranty clause, you don’t want to take on responsibility for every piece of IP that has made it into the Open Source project you are using.

We typically resolve this by adding either a “to our knowledge” clause or explicitly excluding parts of the deliverable in this area.

In addition, you may want to include something in the Indemnification clause to cover features that are requested by your client, but might infringe on a patent or similar concerns. Typically, the Indemnification clause does make you responsible in these cases and most consultants I know don’t have the resources to do patent searches on every feature that is requested by their clients. If you write code that contains infringing IP and your client is sued, you would be on the hook to pay for any and all or your client’s damages, including legal fees. The knowledge qualifier we use handles this situation as well, and you can also handle it with a specific carve-out if needed.

Hopefully this information will be useful to some of you the next time you’re reviewing a contract for a project. If all of this is new to you and you work in this space – I highly recommend talking with a lawyer who has experience with Open Source.

If you’re in the Denver area, I highly recommend working with Ryan Howell at Rubicon Law Group. We met in 2007 at the first StartupWeekend in Boulder and he’s been working with me and Crowd Favorite ever since.

Some contracts also expressly forbid the use of Open Source software and/or software licensed under a specific license as part of their standard terms. Getting this fixed is generally not a problem since you and the client should be in agreement that you are planning to use Open Source tools in the project. I’m assuming we’re all used to dealing with this one already, but wanted to call it out as well.

We put up the first entry in the showcase (the Carrington web site – very meta) and will be adding a few more sites in the near future; but really we’re excited to see what you have been building with the Carrington framework. Hopefully this is a nice way for us to offer a little publicity for Carrington designers and developers and a nice way for people to see what can be done with Carrington.

# | Visit Site »

When I bought the original MacBook Air it came with a pair of video cable adapters, one for DVI and one for VGA. When I bought the second generation MacBook Air it didn’t include any video adapters; and Apple changed the video port connector so that the old video adapters don’t work with the new Air.

I sense a trend here…

Unfortunately my AT&T contract didn’t allow for the cheap upgrade, so I looked a couple of options:

1. Cancel the second (iPhone) line and pay a $145 penalty, then create a new second line and get the iPhone 3Gs for $299 (total cost: $299 iPhone + $145 penalty + $35 activation fee = $479).
2. Purchase the iPhone 3Gs as an upgrade on the iPhone line for $499 (total cost: $499 iPhone + $18 upgrade fee = $517).

I was leaning towards the first option to save a few bucks, twitter’ed about it, and got this response from Dougal:

…have you read about the possible discount if you buy the new #iphone via a #bing search?

A quick search resulted in this explanation, which led to reading more on the Bing site and the following option:

Purchase the iPhone 3Gs as an upgrade on the iPhone line for $499 with a 35% discount via Bing Cashback (total cost: $499 iPhone + $18 upgrade fee – $174.65 Bing Cashback = $342.35).

That’s only a few bucks more than the $299 new line cost without a penalty – which seemed like a fair price to me. It was definitely the best option for me because with option #1 above the $145 penalty wouldn’t have received the discount, resulting in that option costing $374.35.

The Bing Cashback system is a little uncomfortable to use. The discount isn’t referenced or displayed anywhere on the AT&T site or in the checkout process – you have to trust that you will indeed get the cashback check. I figured this was worth the risk – and that Microsoft with this being a push to get people to use Bing, they would probably care about making sure I had a good experience and make sure I got the discount.

Things didn’t go smoothly, but I don’t think it was Bing’s fault. AT&T’s site was having problems and kept kicking me out. I think that caused the transaction token to get lost or not applied properly. Bing Cashback has an FAQ describing what to do in these situations.

I followed the instructions, sent in the order # and a PDF of the order confirmation email, and a day later the credit appeared in my Bing Cashback account. Took about 5 minutes work or so, seems like a fair trade-off.

So I’ve used Bing for the first time – and it seems to have gone pretty much as it was supposed to. I typically just buy everything online through Amazon since I have Prime, but I’ll certainly consider Bing Cashback in the future for larger ticket items.

And I decided to blog about it. I’d say their promotion/campaign worked in this case.

David has excellent wardrobe taste as well, as evidenced by his Crowd Favorite t-shirt.

# | Visit Site »

Of course, not everyone uses all of this flexibility. A number of conventions are typically followed in theme development; mostly stemming from the structure of the “default” theme that ships with WordPress. One of these is the footer.php file.

In many themes the footer.php includes the wp_footer(); call, which in turn allows plugins to add information to that part of your HTML page. This is commonly used by analytics, widgets, etc. that need to load code in the page.

All themes should have the wp_footer(); code in them – it’s important so that plugins that need that call can work properly. It’s important enough that the theme upload process at WordPress.org checks to make sure that the call exists. I think this sort of sanity checking is excellent – it allows WordPress plugins and themes to work nicely in conjunction with each other.

That said…

As previously mentioned, one of the great things about WordPress themes is their flexibility. The wp_footer(); can exist in any file, not just in one called footer.php.

When a plugin makes an assumption about where to look for this call and shows an warning message like this one:

Warning wp_footer(); not found in your footer.php file, this might mean this plugin will not work!

without checking the other theme files to see if wp_footer(); is there or not, it causes the user to think that the plugin and/or theme may be broken. If you’re going to take the trouble to check files for a function call, don’t make assumptions about where you decide to look for the call. Allow themes to innovate, create new best practices and do interesting things – without concern of plugins complaining because they are expecting a certain convention.

This was brought up recently with our Carrington Blog theme¹ – but it’s a bigger issue than just one person using this particular theme; hence this post for the general community.

1. For users of our Carrington themes, I can assure you that all required theme hooks are present and anything requiring wp_footer(); has what it needs to work just fine. [back]

Changes since beta 1:

• Added tag reports. I’m pretty pleased at how these work – you type in the name of a tag you want a report on, it will auto-complete just like in the tags form on the New Post page, and then bring back the tag report when you hit Add.
• Added nice re-flowing code so that reports take up all available horizontal space when displaying.
• Added some additional refinements to the overall Popularity list at the top of the reports page.
• Added a Last (n) Days option to the widget (you can configure the # of days for the widget).
• Removed tags from category reports list.
• Fixed an issue with AJAX deletion of comments.
• Fixed a divide by 0 error that I’m not sure how could happen, but apparently did for someone. The code is more robust now anyway.
• Don’t add JavaScript code to the post content if not using the API (default) method of recording views.
• Works around a broken data situation where there are no rows in the Popularity Contest options table. I have no idea how you’d trigger this situtation, and still can’t reproduce the issue – but now the code works around it. Thanks to Dave (who apparently has never heard of Hanlon’s Razor) for finding the cause of the issue.

Known Issue in beta 2:

When installing for the first time, the WordPress plugins page reports an error:

Plugin could not be activated because it triggered a fatal error.

with an empty “fatal error” message. It also successfully activates the plugin and creates the proper default settings – everything seems to work just as planned. I spent a few minutes playing with various things, but without any error message or anything in the error log, I haven’t found the cause of this yet. If any other devs have time to check this out, I’d certainly appreciate the help.

Aside from this and perhaps a few minor tweaks based on feedback, I think this is just about ready for the final 2.0 release.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter or you can try the WP Support Forums.

The new version of WordPress Mobile Edition is really a developer release. This version adds API access so that other plugins can participate in mobile device checking and add to the settings page for WordPress Mobile Edition.

I was contacted by a developer who was interested in adding to the plugin, and after reviewing his proposed changes that integrated with his (account required) service, I thought they were interesting but would be better as a separate plugin rather than part of the default distribution.

As a result, I added a couple of simple APIs that gave him the access he needed. I’m releasing this new version so anyone can build a plugin that leverages, enhances or extends WordPress Mobile Edition.

The download and more information are available on my WordPress Plugins page.

If you have any trouble with this, please contact the WordPress HelpCenter (512-788-9236) or you can try the WP Support Forums.

I get a lot of requests for features/changes that are specific to someone’s needs. Since (unfortunately) I can’t build specific features for each user into the general plugin, I’ve done the next best thing – I’ve added hooks and filters so that other folks can write plugins for Twitter Tools just like they can for WordPress.

To make sure these hooks and filters work properly, I’ve created three plugins for Twitter Tools that provide commonly requested features:

• Bit.ly for Twitter Tools – enables shortening your URLs with Bit.ly and tracking them on your Bit.ly account.
• #hashtags for Twitter Tools – enables adding hashtags to your blog post tweets.¹
• Exclude Category for Twitter Tools – enables not tweeting posts in chosen categories.

Each of these plugins needs to be activated individually from your Plugins page, and adds their configuration options to the Twitter Tools settings page. You can grab the latest development version of Twitter Tools and these additional plugins from the official SVN repository:

http://svn.wp-plugins.org/twitter-tools/trunk/

I’ve been working on these and doing a bunch of testing this weekend, but I’d love to get some additional testing and feedback on these before I do an official release. Let me know how they work for you – and think about some plugins of your own to write.

1. This uses a fairly complex method of trimming the title as needed to make room for the hashtags – patches to improve/simplify that system while maintaining the functionality are very welcome. [back]

# | Visit Site »

Regardless of my intent, in retrospect I regret the way in which I raised the topic and how I authored the post. I’ve never (intentionally) used this blog as a lightning rod or flame bait, and I didn’t intend to start with that post. My sincere apologies to the theme devs that have recently GPL’ed their code (WooThemes, StudioPress, iThemes and any others).

At the risk of sticking my other foot in my mouth (wouldn’t be the first time), I’d like to revisit one of the core issues around these paid GPL themes, using the following scenario as an illustration.

Imagine: a client comes to me and asks to me to build a site for them using WordPress and a paid GPL theme. The ciient also wants a set of customizations made to the theme and site functionality. Some of the custom functionality requested is different visual treatments for each post, based on the post category. This is a fairly common request for larger publishing sites, and one of the reasons we built the Carrington CMS theme framework (which automates this).

The approach I’d take here is to use the paid GPL theme, and integrate the Carrington framework for handling the post display with custom templates in the paid GPL theme.

Now (assuming the client is fine with releasing the code) I have at worst a reference implementation and at best a working theme that could be useful to other developers, end-users, etc. in the WordPress community.

Everything in the chain (WordPress, the paid GPL theme and the Carrington framework) are all GPL licensed. My preference would be to make this code available so that others can build on it as well. Developers love examples, and I think it would be useful to show how easily the Carrington framework can be surgically integrated into a theme to provide certain functionality and make their lives easier.

What would the reaction be if I released this code?

I think it’s clear from the comments on my last post, there are some people in the community that would think this “isn’t playing fair” or “shows lack of respect”.

Isn’t that the opposite of the spirit of Open Source and the GPL? Shouldn’t we be celebrating the ability to share code and build on what each other has created?

I obviously have a vested interest in the WordPress ecosystem remaining strong. I also want people to be able to make a commercial living in that ecosystem (my team included).

However, I don’t think it’s reasonable to build that ecosystem on the premise that we should ignore certain freedoms of the GPL – and I feel like some folks are asking for that to happen.

I think it’s worth discussing.