Tag: open source

Yourls
For a long time I’ve wanted short URLs for one of my sites. Finally I figured out a short URL, picked up the domain, and said “It would be great if I could redirect posts with this! But how?”

As it turned out, I was making a mental mountain out of a miniature molehill. I do that sometimes, get all caught up in a non-meaningful detail. This was easy, it wasn’t super complicated, and it was fast. On the scale of things where WordPress is the easiest (1) and MediaWiki is the hardest (8), this landed next to Zenphoto (4) and was about the same (3 or 4, depending on your skills). It requires more RTFM than WordPress, and I had to do some things manually.

Setting Up Your Domain

First buy the domain. This part is obvious, I hope. Since I’m on cPanel, I added my new domain as an addon domain to the master. This let me have the short domain (do4.us let’s say) hosted off the main domain.com site, without making a separate account. If I’d wanted to map a domain, I would have parked instead of addon-ing.

To add an addon domain in cPanel:
1. Enter the domain for the new addon domain into the New Domain Name field.
2. Enter the main FTP username for the addon domain in the Subdomain/Ftp Username field. You can use the one you use for the mani account if you want.
3. In the Document Root field, enter the directory that will contain the addon domain’s files.
4. Enter the password for the addon domain into the Password field.
  - Make sure you use a secure password.
  - You can have cPanel generate a secure pasword for you using the Generate Password feature.
5. Confirm the password in the Password (Again) field.
6. Click Add Domain
7. To add files to the addon domain’s home directory, click the File Manager link, or use FTP/SSH like normal people.
Once I did that, and DNS propagated, I was ready to go.

Installing the App

I decided to use Yourls for this, since my friends use it, and I know (in that internet way) the guys behind it. Hi, Ozh.

That said, their install doc was screwed up. For 1.5, it says to edit a file that apparently isn’t included in the build. That’s okay, since I just used SVN anyway. The directions are very much geeky. This is not a simple WordPress install.

What I did was first make a database domain_yourls and added my DB user account to it (I never use my domain FTP account). Then I ran an SVN checkout from googlecode to grab the files into the root of my add-on domain: svn checkout http://yourls.googlecode.com/svn/trunk/ .

After that, it’s the manual editing of the config file (the sample of which is not included in the 1.5 zip) and then I went to myurls.com/admin/ to finish setup. I had to grab the .htaccess file sample, since mine didn’t copy down (my own fault there).

Configuring the App

Install the YOURLS: WordPress to Twitter plugin. Even if you don’t plan on using the auto-tweet function, this is the easiest way to get your URLs made. The “hard part” here is setting up a Twitter ‘app’ for the first time. If you’ve done it before, it’s not terribly hard, but with all new things, it’s scary. Ozh’s directions are painless, thankfully, and then … you’re done. And you have your own Short URLS!

What’s Missing?

Two things, and neither are YOURLS fault!

1) Twitter doesn’t know that three different URLs (domain.com/postname, domain.com/?p=2 and do4.us/2 for example) are all the same URL. That means if you use those Twitter Rewteet buttons on posts, it doesn’t show up the same way, and the ‘count’ is off.

2) There isn’t an easy way to tell Jetpack to use my short URLs instead of my site’s full one. Edited to add: By this I mean only in the ShareDaddy links. Like the ‘tweet/email/facebook’ ones. Actual shortlinks work perfectly.

I suppose a third is ‘Damn it, Twitter, stop shortening a short URL!’ but that’s a different rant.

Should you do this?

I think so, but then again, I’m weird.

Read Also…

Otto – Using YOURLS with WordPress

Rev. Voodoo – How I Set up Vudu.me URL Shortener With Yourls
9 January, 2012
Supporting Open Sourced Clients

You’re hired to build a website and you decide that the best tool for the job is an open source application. So you install it, configure it, add in plugins, tweak the design, and make it a perfect site for your client. You explain how the CMS works, how they add pages, media, etc, and hand over the keys. Everyone’s happy.

Then a month or so later, the CMS releases an upgrade. Your client clicks the upgrade button (because most CMS tools have made that easy) and it installed, but now the site is broken. They contact you, complaining, and you end up spending hours of your time trying to calm them down, complaining to the CMS folks, and being grumpy.

And for a lot of you, this is your own damn fault.

I know a lot of website-building consultants, and I’m not saying this lightly. As a website builder, it’s incumbent on you, the person who installed the CMS, to make sure your clients understand the implications of that CMS, how upgrades work, and to arrange for support, just like you would for any vended product. Basically, if you don’t communicate and educate, you’ve done this to yourself.

Know This Is Not Different

Installing an Open Source product for a client is absolutely the same as installing a traditional, closed source, vended product. It certainly feels different, since there is a far more casual approach to a lot of things, but at the end of the day, your relationship with your client, and theirs with the software you install, is exactly the same, regardless of where the software came from and who wrote it.

A lot of companies worry about Open Source since it’s complicated and nigh impossible to sort out who you can sue if things go wrong. What happens if they vanish? What happens if it breaks? Really it’s not that different. If Microsoft went bankrupt today and closed all their doors, you’d still have everything you bought, but they’d be gone and you wouldn’t get any more help from them. Ditto Apple, and everyone else. In fact, it’s just as likely that a major Open Source app will vanish as it is a Closed Source, or bought out, or no longer supported. And at least with Open Source (and anything GPL’d), the code is mine to maintain as I see fit.

But really, installing a product is installing a product, and the work you do and the support you provide is the same.

Know Your Product

Never install a product you don’t know how to use. Personally, I never install a product I don’t use regularly (which is why I generally only install WordPress, and turn to Andrea if I need help with domain mapping plugins). My reason is that if you use a product, you know what you’re getting into, how it works, and preferably how to tweak it. Some of what you need to know about the product depends on how you plan to support it, but a good rule of thumb is that if you’re installing it for someone else, you either better be an advanced user of it, or know how to get answers, fast, without restoring to forum posts like “Help me ASAP! My client is down!” You’re a professional, you’re expected to learn to use your tools and act that way.

This doesn’t mean you have to know everything, but remember that your clients can use Google, and if they know your handle is ‘Ipstenu’ and they’re using WordPress, they just might search for “Ipstenu WordPress” to see what kind of person you are. So if they search for you and see you being snotty, or using l33t/IM speak in the forums, they might question your professionalism. But if they see you asking the questions they’ve asked of you, they may doubt you. A good idea is to be honest “I don’t know how to do that off the top of my head, so I’m going to research it and ask around.” Network. Ask your friends (you do have friends in your product’s community, right?) and keep in mind your visibility.

Know the Future

We can’t predict the future with any long-term accuracy, but we can prepare for it. If you choose to use a product, you need to know where it’s going. The day to find out about new features is not the release day, nor is it even the pre-release candidates or the betas! You need to be proactive, and keep in touch with the project, where it’s going, and how that impacts you. Every open source product allows for ‘nightly’ builds. These are the things you generally don’t want to run on production versions of websites, but that doesn’t mean you shouldn’t run them on your site. Install the nightly release on a server, set it up so it auto-upgrades every night (or if you use subversion, set up a pull every day or every x hours). Include some sample data, include all the plugins you use on your client sites, and test it at least every week.

Doing all that is a lot of why, which is why some people don’t offer ongoing support (more about that in a minute). Even so, the only way to know your product is to know it. If a product is important to your bottom line, then it’s imperative you know it well. Pay attention to what will and won’t be changing in the next version, and if possible, know why that’s happening, so if your client asks “But why?” you can answer.

This is where I feel Open Source has a clear advantage to closed source applications. Getting on the Microsoft Beta test list is harder than finding parking at the mall the weekend before Christmas. Getting on an Open Source beta test is about as easy as blinking. You can download and test all you want, every day, without asking special permissions.

Know What They Need

Before you go anywhere with a client, you need to ask them what kind of support they want. Are they going to pay you just to build the site, and then you walk away? Do they want to pay you a smaller fee per annum for support, a set fee for upgrades, or hire you at your normal rates to bail them out? Don’t let them drive your decision, though. You’re the one doing the work, and if you have zero interest in ongoing support, be upfront, tell them you’re just going to install it and they need to find other resources for help.

Don’t be a dick about it either, of course. Give them a list of people you know are good for help, some resources for the product, and maybe you can work out a deal with your friends. You get a small percentage of any client referred, for example, to your friend Bob who loves helping people dig themselves out of a hole.

Know What They Know

Any time you install software for someone else, you need to teach them. At the very basic level, they have to know how to use the product, otherwise you’ll get them emailing you new content to post for them. If you want to support that, great, but most people would rather not, so you explain how it’s used. Write up a very basic document for it, save it as a PDF, and include it in your deliverable. Update it when new versions come out and mail it to any client still on your list (i.e. the people who’re still paying you) or post it on your website for anyone to download.

Once your client knows how to do the basics on the site, go back to what level of support you’ve settled on. If they’re going to maintain the site themselves, you need to make sure they know the basics for that too! How to install a plugin, how to upgrade, and so on and so forth. This will make them appreciate you, and hopefully recommend your services to the next guy. Treat people well, it’ll come back to you.

For a product like Drupal, which doesn’t have a full-version upgrade as a one-click option, I usually tell people “Hire someone. It’s a pain.” Beyond that, however, you need to make sure they understand what new versions entail. A lot of people don’t know that WordPress considers a point release to be a major upgrade (i.e. going from 3.1 to 3.2 is a full new version of WP, but 3.2 to 3.2.1 is not). They need to understand that, so when they do upgrade, they know what they’re getting into and aren’t surprised by, say, a new admin menu.

This goes for plugins and themes as well as the basic product. Teach them how to edit themes the ‘right’ way. Explain that they may want to make a duplicate of their site to test upgrades on because, while most work just fine, you should CYA and so should they.

Know How To Communicate, Damnit!

Everything is built off of good relationships with your clients and the product. As we all know, the key to a good relationship is communication. If it’s not painfully obvious, you need to communicate clearly with both of them. Learn how to help non-techs, and learn how to report possible bugs to techs. Bridge the gap between the two, and learn how to translate, because sometimes that wild bug is from your client doing something no one predicted (it happens). You cannot exist in a vacuum, after all and no one’s a mind reader.

When you finish a project with a client, they should know exactly what to do to use the product, have directions on how to upgrade (or how to contact you), how to get help, and what to expect from you in the future. Clearly communicating these things will result in a happier experience for everyone. Or at least an opportunity to do the “I told you so” dance.

What Don’t You Know?

What are some of your tips and tricks for supporting your clients with open source products?

2 November, 2011
SVN up your install on Lion
Cron isn’t reliable, since Apple uses launchd. I’m not the only person who grumbles about this. I know cron. I don’t know launchd, having never had a reason to learn it, so this took some doing. And no, I’m not using a GUI app to write this stuff for me, like LingonApp, since ti feel if I do that I won’t learn how it works.

My goal was simple: Update my local copy of an app (WordPress) when I logged into my computer. Obviously this won’t work if I have no access to the Internet, but that’s okay.

I made a file called wordpress.svn.updater.plist and put it in ~/Library/LaunchAgents/

The content of the file is as follows:
```
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>wordpress.svn.updater</string>
<key>ProgramArguments</key>
<array>
<string>svn</string>
<string>update</string>
<string>/Applications/MAMP/htdocs/</string>
</array>
<key>RunAtLoad</key>
<true/>
</dict>
</plist>
```
So basically every time I log in, SVN updates my install of WordPress, which is in /Applications/MAMP/htdocs/ as I’m using MAMP. I tried it with ~/Sites/localhost/ which is an ln link back to the MAMP folder, but according to Console (where I read my error messages), that didn’t work. If I hard coded the path, though, it was fine.
30 October, 2011
GPL Freedoms – Yep, Porn’s Good!
Did you know you can use WordPress for a porn site?

Did you know you can use Drupal to show autopsy pictures?

The freedoms of GPL don’t just extend to the software itself, but to how you use it. See, most of the time when we talk about GPL freedom, we’re talking about how you’re free to take the code and turn it into a monkey if you want to. But lately, there’s been an effort to remind people that part of GPL also means we don’t restrict your usage either.

WordPress has a link to ‘Freedoms’ at the footer of all admin pages, and that duplicates the Bill of Rights found at WordPress’s Philosophy:
WordPress is licensed under the General Public License (GPLv2 or later) which provides four core freedoms, consider this as the WordPress “bill of rights”:
- The freedom to run the program, for any purpose.
- The freedom to study how the program works, and change it to make it do what you wish.
- The freedom to redistribute.
- The freedom to distribute copies of your modified versions to others.
Drupal doesn’t spell it out as clearly, but given that they have fetchgals, which can pull in thumbnails of porno pics (if I read that right), I feel confident to say that Drupal doesn’t care what you use Drupal for. Joolma! puts a lot of stock in people using their product for their communities and nowhere did I find note of a limitation of what you cannot do.

The point is valid, however. You can use WordPress, Drupal, Joomla! and pretty much any GPL software for whatever purpose you want, moral or immoral, legal or illegal. This is interesting when you compare it to most EULAs, like Microsoft Office:

7. SCOPE OF LICENSE. The software is licensed, not sold. This agreement only gives you some rights to use the features included in the software edition you licensed. Microsoft reserve reserves all other rights. Unless applicable law gives you more rights despite this limitation, you may use the software only as expressly permitted in this agreement. In doing so, you must comply with any technical limitations in the software that only allow you to use it in certain ways. You may not
[…]
• use the software in any way that is against the law;

GPL doesn’t tell you that you can’t use it in a way that’s illegal, and perhaps Microsoft only does to escape a potential lawsuit for someone saying “Aha! You used Office to draft your Mainifesto!” We live in over litigious times. Open Source, by telling us ‘Do what you want, it’s not our beef.’ removes themselves from those issues cleanly and without ass hattery.

One of the tenets of American Law is our freedom to speak our mind. Part of being an American Citizen is that you have the right to defend your beliefs, no matter how much I oppose them, and so long as no one breaks the law, that’s fine. I can ask you to leave my house if you do it on my private property, and you can ask me to leave yours. But if we meet on the street I cannot have you arrested for that. I will defend your freedoms just as you must defend mine, regardless of any agreement or lack there of.

This applies to Open Source because I have the right to use WordPress, Drupal or Joomla! in ways you may find distasteful. As long as I’m not violating the agreement of my ISP, the laws of where my server is located, and the laws of my nation, I’m allowed to call you names, insult your heritage, and show nudie pics of pretty girls. On the other hand, I cannot publish your personal information (it’s a violation of invasion of privacy) and I cannot post naked pictures of you without your consent. Actually, my webhost won’t permit and naked pictures at all, so there’s that.

So when you see a site run by WordPress, Drupal or Joomla! that’s doing something you hate, there’s very little you can do about it. Report it to their webhost if you think it’s breaking the law, but otherwise celebrate people in their freedom.
10 October, 2011
Risk Theater and Open Source Testing

We make multiple test environments and platforms, testing with hundreds of users. We perform stress tests (how much traffic can my site take?), and have an obscene amount of checks and balances to ensure that only code that is good makes it into the file product. We have teams who question every change asking “Do you need this?” or “What’s this function for?” We audit every update process and ensure that our work is as good as we can make it. This is all done, we say, to reduce our risk. Our software, we insist, will be better if we do all these things.

But the failure rate has not dropped.

Initially, when a product is released, there’s a spike of failures. We didn’t anticipate that, or this didn’t work like we expected it to. Those are not classified as ‘failures’ but as kinks to be ironed out. Six or seven months down the line, we’ve released another set of itterations to fix the worst offenders and our failure rate drops to a comfortable rate where, most of the time, everything’s fine.

What if I told you that one in five IT projects was a success?(Source: Statistics over IT Failure Rate)

What if I told you that all your myriad checks, balances, testing, forms and CYA dances didn’t make anything less risky?

What if I told you it was all Risk Theater.

Of course you can do things in a less risky way. If given the choice between dismantling a bomb in a nice quiet room, where you have all the time in the world and a blast shield, or doing it on the back of a van while being shot at and you only have 30 seconds, everyone would point at that room and say ‘Less risky!’ And they’d be right. The problem with risk is that there are often, if not always, external forces that perpetuate risk.

We have to ask ourselves “What is risk?” We can look at it mathematically. Risk = {si, λi, xi} – and most of us have no idea what that means. Risk is not a magical number that says “Defusing a bomb is this risky.” Determining risk is how we discern how likely something is to happen, and from that, what is the likelihood of an unwelcome outcome.

Too often risk is defined as risk = likelihood * consequence and safety = 1-risk

This can misinform: acceptable risk is a consideration of likelihood ANDconsequence, not a simple multiplication with safety as the additive inverse of risk. Acceptable risk and safety are normative notions, changing with situations and expectations, and must be assessed accordingly. (Source: Woody’s Perspective – by Steven A. “Woody” Epstein)

Risk analysis, for all it’s a mathematical discipline, is just that. A discipline. That means the numbers matter far less than you think they do, and if all you do is look at the numbers and say “But we’ve predicted a five point uptime!” then you’re ignorant of the truth.(A five point uptime refers to the claim people make of providing 99.99999% uptime. The five 9s after the decimal point are feel-good numbers/) The trick to it all is that variation is something computers are phenomenally bad at handling. Look at your computer. It’s what can be best described as a ‘brittle’ system. If you throw something a computer’s never seen before, it tends to react poorly, because unlike the human brain, it can’t adapt or improvise. It can’t know “Oh, you meant ‘yes’ when you typed ‘yea’” unless some programmer has put in a catch for that. On some systems, it may not even know the difference between an uppercase Y and a lowercase y.

Variation is nature. It’s reality. It’ll never go away, either. The point of risk analysis is not to come up with that number to say ‘By doing foo, we are x% less risky.’ The point is to look at the system and understand it better. The point is to learn. The act of explaining and defining the process, whatever it is from changing a tire to pushing software to a few hundred servers, is what makes a process less risky. You understand what it is you’re doing, and you can explain it to someone so they too can understand it, and now you know what you’re doing. The numbers will come, but they’ll also change over time due to variation.

We mitigate our risk by understanding, testing and documenting. But just as you can never have 100% uptime on a system (you have to upgrade it at some point), you cannot excise risk entirely. On the other hand, we cannot ignore the need for testing.

A woman named Lisa Norris died due to a software error, caused by a lack of testing. All the safety checks, the manual monitoring and brainpower failed because the automated system wasn’t tested. Prior to the automated system going online, the old way was for people to manually transcribe medical dosage. This was felt to be ‘high risk’ because there was a risk of transcription error. However nowhere in the incident report were any ‘manual errors’ noted, prior to the automated system being used. We can assume, then, that any manual errors (i.e. transcription errors, the risk the system was meant to abrogate) were caught in-flight and corrected. The automated system does not appear to have ever been tested with ‘real world’ scenarios (there’s no documentation to that affect that anyone investigating the situation had found). If they had run simulations, testing with data from the previous, manual system, they may have found the errors that lead to a woman’s death. (Source: Lisa Norris’ Death by Software Changes – by Steven A. “Woody” Epstein)

There remains a possibility, however, that even with all the testing in the world, that the error that led to Miss Norris’ death would have been missed. So how do we make testing better? As long as we’re only testing for the sake of testing (i.e. it’s expected, so we do it), or we follow the standard test plan, we miss the point of dry testing. Even people who stick by their ridgid test scripts are missing the point.

Open Source software, however, gets the point.

You see, we know we can’t test everything, and we know that we’re going to miss that one variation on a server where code that works a hundred times on a ninety-nine servers will fail on that one where it has a tiny difference. And yet, if a million monkeys banging on a million keyboards could write Hamlet, then why can’t they fix software? They can help cure AIDS, we know. Crowd sourcing knowledge means that you let the monkeys bang on your data and test it in ways you never imagined it being used. No longer driven by a salary (and that really does lock your brain in weird ways), the monkeys (and I’m one of them), cheerfully set up rigs where we can roll back quickly if things break, and start just using the iterations of software, coming up with weird errors in peculiar situations.

We always talk about how we want to lower the bar and make products more accessible to more people. Make it easier for them to use. In order to sustain that model, we need to embrace the inherent risk of software and teach the users how to correctly perform basic troubleshooting and report real errors. To often we write our code in a vacuum, test it in a limited fashion, and release into the wild knowing there will be a second release to fix things. As development matures, we push out more changes more often, small changes, so people are eased into that new thing. We step out of isolation and embrace the varations of how our product will be used.

Now we need to get our users to step out of their isolation and join the monkeys. We can’t make things better for everyone unless everyone is a part of the improvement process. We must ease these users into understanding that every software product is ‘in progress’, just like we taught them to accept that all webpages are perpetually ‘under construction.’ Our dry tests will never be complete until we can determine how to safely bring them in. Maybe we make smaller changes every day, like Google does with Chrome, such that they never notice. Or maybe we ask them to ‘check the box to join our test group and get cool features before everyone else!’ But we must do it, or we will fall behind in giving the users what they want, and giving them a solid, safe, secure product.

Until then, we’re not analyzing or assessing actual risk, we’re merely players in risk theater.

27 September, 2011
The Morality of Forking
Having already established that Forking is Legal, I felt it best to take the other end of the argument.(This was intended to be all one post, but at about 3000 words, it needed to be split up.)

Clarification here. Jigoshop is a product of Jigowatt. I call them Jigoshop in both my posts because it’s easier for my brain.

Gil Rutkowski remarked (without knowing I was already writing this):

Funny how people pick and choose between the “SPIRIT” of the GPL and its literal legal application to fit their argument. (@flashingcursor on Twitter)

We often sum up GPL as “Do what you want with this software. Just let other people do what they want with the software you make from it.” If you’re not familiar with it, I think I can sum up the spirit of GPL as “Don’t be a dick.” (Wil Wheaton in Exile) People get in a lot of arguments about the ‘spirit’ of things. You’ve probably heard someone complain “He’s following the letter of the law, but not the spirit.” Basically what that means is someone is obeying the law, but not what it means.

How can that even be? If the law is the law, then the law is the law and there should be no wibbly wobbly involved! It happens because of intent. The intent of the law in general is really something we shouldn’t have needed to be told in the first place, when you think about it. Primum non nocere: First, do no harm. Doctors are taught this, and you’d really think that’s self-evident! And yet, even the US Declaration of Independence starts out “We hold these truths to be self-evident…” If they were self-evident, why are we saying thing?

People are selfish. We care about ourselves first, then the people closest to us, and so on and so forth. To say the ‘spirit’ of the law means we’re no longer actually talking about the law as a legislative statute, but about the idiomatic application there of. We’re now talking about how we feel the law should be, which is pretty iffy territory. Talking about the spirit of the law brings up things like the moral ambiguity of the law, and the ethics we try to impose on others. What’s ethical for me may not be so for you, and so on.

So what does the moral aspect of GPL have to do with the recent forking of Jigoshop’s eCommerce plugin? Interestingly we can see how both parties ended up at the fork because they were selfish. Jigoshop didn’t want to give up control and neither did WooThemes. Neither was willing to concede, and in a way, they both ‘lost’ because of it.

Was Woo being a dick to fork the plugin? Yes. And no. You have to keep this in perspective.

You see, no one has made a ‘Killer’ eCommerce plugin for WordPress. Not even Jigoshop. From what I’ve been told, Woo has struggled to make their own killer plugin for eCommerce, and failed at it. I will leave it to others who actually use eCommerce on their sites to determine which plugin is queen, but I feel comfortable saying that taking someone else’s work, even when you credit them, can be a dick move.

At the exact same time that WooThemes is being a dick for forking, they’re doing a right thing. No that’s not a typo, they are doing A thing that is right. We all know that ‘hacking core’ for WordPress (or any app) is a terrible thing. Merging changesets is a nightmare, no matter what tool you use, and a fork makes it just as hard to incorporate changes. So would not a better solution be to make a WooTheme add-on plugin that just changed the parts of Jigoshop they didn’t like? A Woo/Jigo integration plugin?

That would be a wonderful, perfect world. Let me know when we get there. Sometimes the direction of a plugin is such that you have to fork it to do what you want. The developers don’t want to follow your dream of unicorns and puppies. Until we reach the perfect world, we fork. Now, it took a bit of reading to verify that WooThemes was unable to make their desired changes without editing core plugin code. That left them with only a few viable options. They could submit the changes to Jigoshop and hope for the best, or they could hack the Gibson. Basically, this was the best choice for WooThemes and really, nothing’s wrong with that.

The problem is that WooThemes is going to be making money off this acquisition. Their WooCommerce plugin will be free, just like Jigoshop, but just like Jigoshop, they aim to make a living off the plugin. Off someone else’s work. To be fair, that’s what I do. I support other people’s ‘stuff’ all the time. I’ve not written a lick of code for Windows in years (except DOS and PowerShell scripts) but their products pay my bills. Does that make me a thief?

No, it makes me an opportunist. WooThemes is being opportunistic as well. Remember how I said we are, all of us, selfish? Well so is Woo. They see a chance to make money and use a plugin that works, and not their own with a weird history. (Did you know Nacin was once going to head up WooCommerce before he was snatched by Matt? That’s fun to look at in retrospect.) Woo had a series of unfortunate issues with their own plugin, and it never worked right. They weren’t a dick because they talked to Jigoshop first (they didn’t have to), and I rather hope they said ‘Okay, we’re going to agree to disagree on the direction of the plugin and fork it.’ If Jigoshop first learned of the fork via Woo’s blog post, then they were entirely dicks.

Was Woo being a dick to ‘head hunt’ the developers? Yes. And again, No. Yet again, perspective is important.

I said before that the developers they ‘stole’ wouldn’t have left if they had a reason to stay. People leave companies all the time for myriad reasons. They also stay with companies for others. In the ‘traditional’ corporate world, people get a job and stay with it for a million years. In the freelance world, though, people switch jobs around a lot more. Even so, people only leave companies for three reasons:
1. They hate it here
2. They found something better
3. They were let go
That’s really it. So if someone chooses to leave a company, options one and two are there on the table, and you have to be honest to ask if they would have left if Woo hadn’t made the offer? And there’s where the dick move possibly lives. Was it Woo’s promise of skittles and beer that made them leave, or was there something wrong at Jigoshop? It’s far too early to point fingers at anyone, especially the developers who may discover they made a poor choice. You have to take risks, after all, or you never succeed.

WooThemes was dickish if they bribed away the developers. But they weren’t if this was just one of those serendipity moments. What if the developers said ‘Wow! Woo shares our vision!’ We don’t know, so we have to speculate, but either way, the decision was the developers and not WooThemes or Jigoshop, so any dickery actually belongs to the devs and them alone.

Since I was asked, my personal opinion is this: WooThemes pulled a dick move which in no way violated the letter or the spirit of GPL.

See the spirit would have been violated if, as another shop did recently, they lifted the plugin wholesale, made a couple tweaks, rebrand it, and released it without telling anyone. You know who I’m talking about here. That was violation of the spirit of GPL. But WooThemes was upfront about this. They talked to Jigoshop first, and everyone seems to have known what was going on before the news broke.

While I dislike that WooThemes did this, I will defend their right to do so (and Jigoshop’s right to be upset) until the day we all stop using GPL.

The whole reason I wrote the first post, however, was the high number of people I talked to who said that the spirit of the law was violated. It really wasn’t. Yes, these were dick moves, but the spirit of the law is the meaning, and the meaning of GPL is that you can’t impose more restrictions on a GPL product than it started with. No one did that. What Woo did was pretty shitty to their neighbor, don’t get me wrong, but it didn’t kill GPL. It hurt feelings and left a bad taste in the mouth, but that’s not the spirit of GPL either.

The Spirit of GPL is freedom. It’s sharing your work, working together, and when you take someone’s work, being open about them and crediting them. And while you don’t have to like what Woo did, they did not harm the spirit of GPL, because we’re all here, talking about it and still abiding by it.

I can but hope that the fallout from this is that we’ll finally have an eCommerce plugin that stands up as the best because of worth and not because that’s all we’ve got, but we’ll have to wait a couple of years for that to settle.
31 August, 2011

Tag: open source

Yourls

Supporting Open Sourced Clients

SVN up your install on Lion

GPL Freedoms – Yep, Porn’s Good!

Risk Theater and Open Source Testing

The Morality of Forking