In brief, Mullenweg believes that, because WordPress is released under the GPLv2 license, all themes and plugins developed for WordPress must also be released under the same license. Pearson disagrees.

This situation has never affected us directly at Soupgiant so we haven’t needed to, and this is important, ask our lawyer if my interpretation is correct. This is a layman’s opinion and should be treated as such.

The battle comes down to these clauses in the GPLv2 license:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works.

–source GPLv2 license

Due to the second clause quoted above, I believe that Mullenweg is wrong. WordPress themes can operate on other blogging platforms with minimal changes. This has been done before with the Sandbox theme for WordPress which was successfully ported to Movable Type.

WordPress themes output HTML with a series of calls to the blogging platform. To output the post’s title and contents in our base theme, we use the code:

<h2 class="entry-title"><?php the_title() ?></h2>
<div class="entry-content">
    <?php the_content("Continue reading " . the_title('', '', false)); ?>
</div>

To output the same HTML in a Movable Type theme, we would output:

<h2 class="entry-title"><$mt:EntryTitle$></h2>
<div class="entry-content">
    <$mt:EntryBody$> <$mt:EntryMore$>
</div>

In terms of a page’s output, the above code is a minor part of the page. The theme’s template is mostly made up of HTML and CSS, HTML and CSS operate in the browser and not in the blogging platform. It’s for that reason that I believe that Pearson is correct in this case.

I acknowledge that WordPress hooks may complicate the matter but these hooks output such a minor part of a theme’s HTML, that I consider the theme uses the platform but isn’t derived from the platform. I’ve left plugins out of this discussion as these are a more complicated matter: they can output HTML or they can build on the platform.

The above said, were I to release a WordPress theme I would probably release it under the GPL as a hat tip and thank you to the community that has assisted me so much. However, if the theme was as complicated as the Thesis theme, I may feel differently about the matter when it’s crunch time.

Again, this is a layman’s opinion and should be treated as such. If you have a layman’s opinion too, we’d love to hear it in the comments.

When we launched Big Red Tin we didn’t set up Twitterfeed immediately.

With manual tweets we could customise the message to provide more details to Twitter users, one such tweet was:

We’ve defined a new term: Web 1.5 http://redt.in/b0KRut ^pw

– source: @bigredtin

We had Twitterfeed set up at this blog’s old location and took the opportunity to compare click-throughs from manual tweets versus automated tweets.

Manual tweets had a substantially higher click-through rate than the automated tweets. I suspect the reason for this is two fold:

• With so many people using Twitterfeed type services, Twitter users have learnt to ignore tweets that appear auto-generated.
• More information can be included in a manual tweet than might appear in an auto-tweet.

Take the post we were linking to earlier, had we been using Twitterfeed the tweet would have been ‘Blog Post: Web 1.5 http://redt.in/b0KRut‘. This provides so little information as to be next to useless. We would have ignored such a tweet out ourselves.

Many of the posts on this site are scheduled in advance, this allows us to publish at roughly the same time each week.

To schedule the associated tweets we use CoTweet. We have a couple of shared twitter accounts as it is, so CoTweet comes in handy for other purposes, but it’s the scheduling feature we use most of all.

If you use Twitterfeed yourself, try disabling it for a couple of weeks and manually tweet in its place. There’s a good chance you’ll be pleasantly surprised when you compare your bit.ly stats.

What we’ve done in Soupgiant, however, is take the blog portion of our website and move it over here to Big Red Tin. The two sites still link to each other. There’s no doubt that the people in charge over here are also in charge over there. It’s one and the same.

We decided to separate the two because we didn’t want to disrupt any one audience.

Soupgiant.com is our sales website. It’s where we’ll put all our information about the products and services we offer. Customers will be able to see the work that we’ve done for other clients and can see if what we can do for them is actually what they want.

Big Red Tin, on the other hand, is just a blog. It gives us a chance to document every single part of our business, from bits of code to design concepts and also choices we make in running our business in the day to day.

Basically we hope that this will become a repository of information that can help people who encounter the same issues we have.

This is the first lesson of Content Strategy and it’s something we are taught all through school but still often manage to forget: Know your audience.

Websites have the added benefit of allowing our audiences to know us. So, in one sense we can work out the audience for a website by asking: What do we want our audience to know about us?

With Big Red Tin we’ve already answered that question earlier in this post: We want to share what we learn from the issues we encounter.

To do that, we’ve split this blog into four categories that we think detail all aspects of our business:

• Behind the Websites details the work we do in coding websites and dealing with content management system (CMS).
• Business is about business decisions we’ve made or the general lessons we learn in running a business, either based on our own experiences or our observations of others.
• Content Strategy discusses the intricacies in honing the content of websites to achieve the greatest value from them. It might be about navigation or website accessibility or the general layout of information on the screen, but it also might be about words and how to use them.
• Design will bring together aspects of graphic design that we deal with. Buttons, images, colours, styles, legibility – basically everything that brings that all important first opinion will be dealt with under the “Design” banner.

There might be people who are interested in all four of these categories but we hope splitting them out makes it easier for those only interested in one or two.

For more specific areas of discussion we have tags. There are many of these and you’ll see them at the bottom of each post. So, if you’re on a post about CSS3 and you want to know more, you can see all our posts about CSS3.

Big Red Tin is the result of a long process of planning, which is the only way to do content strategy correctly. We hope you enjoy what we do here and encourage you to share your experiences in the comments.