Tag: plugins

The Legality of Forking

Update: This post is just about the legal aspects of forking. If you just want to talk about the morality of it, please go read The Morality of Forking.

You may have heard about this. WooThemes hired a couple of developers who used to work for Jigoshop, and forked one of their plugins.

Last week WooThemes announced the hiring of Mike Jolley and Jay Koster, as well as the forking of Jigoshop e-commerce plugin into the soon-to-be-released WooCommerce. Jolley and Foster previously worked for Jigowatt, a WordPress and Magento development shop, spending the last year working on the core of Jigoshop.(WP Candy: Jigoshop team and WordPress community members share thoughts on forking)

When you read it that way, it looks a little weird, doesn’t it? Shady even. After all, this is a case of one company cherry picking ideas from another, and then taking developers to continue working on their version.

Here, read this view of events:

But of course, open source makes it so easy to simply “steal” someone’s idea and hard work. And justifying it by hiding under the umbrella of open source and “legal” forking. (WooThemes Forks Jigoshop and they brag about it)

I’m going to go out on a limb here and present a point of view that many people will disagree with.

It’s not theft.

Freedom is a complicated, annoying, thing, and sometimes having a freedom means you accept the consequences of that freedom. In the US, we have freedom of speech, which means we can bitch about our government if we want to. But that also means someone else, who has the polar opposite of your views, has the exact same right you do. And I will defend that person with my dying breath that they have that right, no matter how much I detest what they’re saying.

You have to keep that in perspective when you start talking about rights and legality. WooThemes had the legal right to do what they did. That doesn’t mean you don’t get to think that it was a dick move, and you may, but what it was, was 100% above-board. They were honest about it, and it was legal. The GPL affords us the freedom to make plugins, fork WordPress if we wanted, and do what we want, so long as we don’t restrict the freedoms even more.

We pay a heavy price for these freedoms, don’t get me wrong. All freedoms have a cost. We all pay for them. Thomas Paine’s famous quote reflects on the ‘free’ part of open-source in a strange way: “What we obtain too cheap, we esteem too lightly; it is dearness only that gives everything its value.” The core code of WordPress is free to us, and perhaps we devalue it for that price. Certainly the unrealistic expectations of many users is that this is a free product, and as such they deserve all things for free.

It’s possible that many people are dismissing this forking because hey, it’s a free world! WordPress is free, the plugin was free, the plugin was GPL, we’re all free to do what we want. But WordPress, when it hands us a dizzying array of freedoms in usage, is clearly giving us liberty that can be easily abused. It’s possible this is the case of abuse of that liberty. To judge that, we have to look at the whole picture.

Woo’s bid to buy out the Jigoshop project grossly undervalued the business and didn’t come close to covering our initial development costs, not forgetting the planning, time and effort both the Jigowatt team and community put into the project.

Woo then made to an offer to ‘collaborate’ which led to their decision to fork Jigoshop. What hasn’t been made public is that collaboration offer included conditions which would have given WooThemes full strategic control over the direction and development of the Jigoshop project in the future. (Jigoshop: Our Forking Views)

So clearly we can see that an offer of purchase, and collaboration, were made. They were felt to be not right. That was Jigoshop’s right and choice. Was it the correct choice? Only time will tell. That holds true of both Jigoshop and WooThemes. But up to this point, the whole deal is above-board, fair and just. And then WooThemes said ‘Well, they don’t want to work with us. That’s fair. We’re going to fork. And we’re going to take their core devs with us.’

This is still not theft.

See, WooThemes had no power to ‘take’ those devs unless Jigoshop undervalued them. That is Jigoshop esteemed their own developers too lightly. If the devs had been happy with their compensation, the direction of the plugin, and the company, they wouldn’t have left.

If you are a company with an open source project gaining momentum, your core developers absolutely must have a vested interest in your company. And not 1%. It has to be a good chunk of the pie. Enough that the developers feel your company is also their company. Then if another company comes along to hire them, the developer is much more likely to tell them, “Buy the company or take a hike.” (Lessons learned from the Jigoshop – WooCommerce fiasco)

In the corporate world, I’ve signed a contract that says, should I leave my company, there are jobs I have legally agreed not to take for 12 months following my termination. My contract also prohibits me from doing certain types of freelance work. Not that long ago, a friend complained that it wasn’t ‘fair’ that we were restricted like that. I looked at her and pointed out “No one made us sign these contracts. We read them, and we chose to sign them.”

I’m no stranger to signing NDAs and other documents that restrict me from telling you things like who banks at the company I work for. I can tell you things that are publicly known, but not things that are not. That sounds fair, doesn’t it? I also can’t blog about my company with certain details, and on pain of being fired, I can’t talk to the press about anything. I don’t have to like it all the time, but it’s something I agreed to and that’s a choice I have to live with. Many of my friends who work in other ‘worlds’ can’t understand how a company can restrict my private life. I point out that I signed a contract that promised I wouldn’t, and I keep my promises. If I didn’t, would I be the person they liked and respected?

No one here violated a contract, lied, cheated, or stole. So why are people chapped and are they right to be so?

Right and wrong are tenuous. What’s right for you isn’t right for me, and that’s a part of why we have the law, which defines right for ‘everyone.’ Of course, we all know that even then, right is subjective. The law is imperfect, we know this, that’s why we have judges and jurys who listen to the situations that surround illegalities and make judgements based on not just the black and white of a situation, but the entire picture.

What WooThemes did was legal and fair. End of story. We cannot stand and shout for the freedoms of WordPress and GPL without defending their actions. That doesn’t mean we have to like them. If this makes you decide to never support WooThemes or Jigoshop again, that’s your choice too, and one I will defend till my dying day. I feel that I should point out here that some people who are decrying WooTheme’s move are the same people who were all up in arms for Chris Pearson’s Thesis theme to abide by the GPL.

We live by the GPL sword, and we’ll die by that sword for as long as we stay GPL. The community clearly wants to be GPL, or we’d not have gone after Thesis with such animosity. That means we have to accept that sometimes what’s right isn’t what we would do. But then again, no one’s making you use the forked plugin.

Someone’s bound to bring up the fact that even Matt doesn’t like forking. That would be incorrect. WordPress is a fork of B2. Matt’s problem with forking is pretty easy to understand:

Forking is not usually ideal because it fragments the market for users

Notice how Matt doesn’t say he doesn’t like it, but that it’s not ideal? That does rather apply to this situation. By forking a plugin, you make two versions of it. Were we not all recently delighted when the TimThumb fork (WordThumb) merged with Tim to fix the problems? Were we not ecstatic when WPMU merged with WordPress to make MultiSite? Multiple plugins that do the same thing mean multiple places to have to patch.

And yet. There are already a handful of similar plugins out there. Having competition drives people to make better products and prevents us from resting on our laurels. It’s great you made the best plugin ever, but now what? It’s true this fork may be damaging to the community, and it’s true that it may have caused hurt feelings. But what matters more is where are Jigishop and WooThemes going next? How will their plugins make themselves notably different?

In the end, if you don’t like it, vote with your feet, but you owe it to yourself to defend everyone’s freedom with the same ferocity you defend your own. Even the people you hate.

29 August, 2011
Ban Hammer 1.6 – Languaged Up!

After a very obvious request, I’ve done my best to make Ban Hammer languagable. That is … it has a language pack and you can add in to it. If you have internationalization fixes to add in, drop a comment here and I’ll email you.

Ban Hammer is available for download at WordPress.org

11 August, 2011
How to Support Plugins

This is not meant to be a perfect, will work for everyone, solution. But if you’ve made your first plugin and you’ve no idea how to support it, this is for you!

I’m going to present this under the assumption that you already understand how to code, even if your coding is about as good as my French. I’m also going to assume that you are a thinking being with the ability to be rational and accept defeat.

History first. I picked up WordPress back when MovableType decided to change their licenses, and I’ve never looked back. First it was just my blog, then I learned all the cool things I could do to it. The turning point for me was when I decided to rebuild my fansite using WordPress. While I do write code for my day job at a very large bank, I spend an awful lot of time troubleshooting for developers.

In a nutshell, I take phone calls (and emails) from very smart, very technical savvy people, asking me questions about things I know nothing about and make them work. I support software I don’t use, I support software I don’t understand, and I support software that’s almost as old as I am. It’s a very weird job, but I like it, and I do well at it, which is why I keep my day job and just play with WordPress! And what do I do with WordPress?

I help in the support forums!

My job made me accustomed to taking weird questions from smart people about a brand new topic, learning what I need to in order to solve the problem, and hand them the information quickly and in an understandable way. My mom loves this, and knows she can call me about anything computer related, and I’ll find the answer for her. When I started helping on the WordPress forums, this was suddenly a skill whose worth could not be measured. I wasn’t afraid to jump in and help out on topics I was unfamiliar with because I knew I could figure it out.

The magic to it, the secret to my power, is that I know how to learn, when to ask for help, and to admit when I don’t know.

That’s pretty much it. And I’m going to teach you how to do it too, provided you’re willing to think, and to admit that you’re wrong sometimes. Don’t worry, I’ll be wrong right along with you!

You are not the only user of your plugin, so be available

Most people who write a plugin do it for a few reasons:

They need to do something special
Someone else needs something special
They want to feel important and praised
They’re a bored genius maniac (see pic on the right)

It all boils down to the idea that we do it for ourselves. There’s nothing wrong with that. Remember, as long as that plugin is just yours, sitting on your server, you could do whatever you wanted. The moment you start handing out your cool ‘just for me’ code to other people, there is a level of responsibility that you have to own up to. You’re now a developer and that means you need to help people. If your plugin is up on the WordPress repository, you are no longer making this for you, but for anyone who needs it. They’re going to ask for help, they’re going to tell you that you did it all wrong, and they’re going to be unreasonable.

If you’re making a plugin that you don’t want to support, this better be painfully clear on the plugin readme.txt, or you will be in running for my asshat of the year award. There’s nothing wrong with making a plugin and abandoning it, but there is something wrong with not telling people that. For the rest of us who are supporting our plugins, make sure it’s clear how they should contact you.

The default expectation is that if I post in the forums and tag my topic with your plugin flag, you will see it and reply. There is no law that says this must be the case, but since it is the common way plugins are handled, you must be explicitly clear to people that you want to use a different method. As a forum helper, when I see someone ask for help on a plugin, I always go look at the plugin readme first. If it says ‘for support, go to…’ I always tell people to do that.

Now that said, you still need to remember to add the RSS feed to your reader, because some people don’t read, and sometimes they’ll let you know of something huge in the forums, and not contact you correctly. I’m not saying you need to reply to them, but think of it as a CYA manuver. There’s a great URL that anyone can use for all your plugins: http://wordpress.org/support/view/plugin-committer/YOURHANDLE

That will update every time anyone posts about any of your plugins. If you need it to email you instead of RSS, I suggest using RSS2Email, FeedBurner or any other web-app that turns feeds into email to alert yourself.

It’s your plugin

At the same time, this is your plugin. You designed it to fill a certain void and damn it, if you don’t want it to have dancing monkeys, then you don’t need to! This has been where I see most developers get into ‘fights’ online. People often have unrealistic expectations for free products, and most of why I charge people for phone/email support is because it gets rid of the stupid requests and keeps me sane. If I answered every email, IM or forum post someone addressed to me with the same attentiveness and response-time I give at my day job, I’d be working 60 hours a week on a free product, with no monetary kick back. I don’t have the time for that. Neither do most people.

The hardest lesson to learn is how to walk away when you feel responsible for your product. Even though these are your users, and these people rely on you, there is a point at which you cannot explain ‘why’ sufficiently for them to understand it. Either they’re stuck in their world, or you in yours, but regardless, you are at an impasse. And this is when you have to walk away. Tell them ‘I’m sorry, but I’m not going to do that. You’re welcome to fork the plugin if you want.’ And walk. Away. Sometimes things are just outside your scope, and if you don’t want to support the addition, you don’t have to. Don’t let people bully you into things.

The expectations of ‘free’ plugins are crazy, and we all know that. It’s like not feeding the trolls, though. When people are unrealistic to you, you’re under no obligation to support them. But also, when things are outside the scope of your plugin, you can tell them that and be done. I’ve said no to people who wanted things added in, even after I spent a day down the rabbit hole applying code to implement their feature, because I neither wanted to support it nor did I find it useful. At the end of the day, it’s my plugin. I decide what it should do.

Don’t forget you have a life!

Most problems people have with plugins are literacy problems. That is they did not RTFM, or they didn’t pass reading comprehension and are over-thinking a problem. I spent 4 hours once at work talking to a woman who didn’t understand what I meant when I said ‘If the folder’s not there, just make it.’ She was certain I was omitting a crucial step, or secret hand shake. This goes back to what I said about why I have a per-hour price for personal support. I don’t have time to walk someone through the basics of how to FTP or edit a file. That’s not the support you need to offer for plugins, and if someone can’t do it, it’s okay to tell them that they need to hire someone. You have a life! Don’t let them take all your free time.

I have other hobbies besides WordPress. I write, I play guitar, I ride my bicycle, I’m in the SCA, I do some volunteer work for bicycling, I’m part of a couple fandoms, and so on and so forth. I have a family and friends and interests outside slaving away at a computer all day and night for no compensation. So I try to balance my time and yes, that means sometimes I walk away from a coding frenzy, but sometimes you just have to. There are commitments in life, and you will have to sacrifice them sometimes. Don’t sacrifice your self, though. Embrace your life and don’t let one obsession rule it. That will help you keep it all in perspective.

Users are people too

Maintaining a plugin will involve sacrifice. The first thing you’re going to lose is free time, but the second is you will lose face. You’re going to get into a fight with someone on the forums, no matter how well you mean. Part of this is because text is an imperfect medium. My father complains about it, because he says it’s not a discussion, but a debate, and most people in the US never took a debate class.

It’s really hard to remember to be polite, especially when these people aren’t reading the damned manuals/readme/directions. I fail at it often enough that I used to joke it’s why I’d never be promoted at work or made a forum moderator for WordPress. Ironically enough, both those things happened roughly within weeks of each other. I suspect the reason is that while I do lose my cool sometimes and write angry, I mean well and try hard to be polite and do good.

Every time I train new people in how to work our tech support, I tell them that from Thanksgiving to New Years, our busiest time of year, everyone will make at least one, massive, giant, phenomenal “Oh dear GOD am I about to be fired!?” magnitude of an error. Without fail, at least one person will promise they won’t, and I write their name on my white-board with the date. Without fail they will make a huge error. The point is that everyone makes mistakes, everyone forgets how to reset a password, everyone forgets something basic, even you. So just remember that.

It’s okay to not know

I don’t know how set up domain mapping. I have to read the documentation every time, and often I ask Andrea or Ron. On the flip side, Andrea has remarked more than once that when she sees a weird .htaccess request, she defers to me. I know what I know, I know what I don’t, and I have no shame in telling someone “You know, I don’t use IIS and I really have no idea how to help you here.” If you don’t know how to do something, say so. Maybe the person you’re trying to help actually does know how to code it, or maybe someone reading it will know.

When you make a BIG change, document the hell out of it

Recently, W3 Total Cache pushed a new version with a lot of cool features and better tools. The problem was that many people found it broke their site. The fix was really easy. Change the new ‘default’ setting for Minify from ‘Auto’ to ‘Manual’ and set it all up manually. The problem was that the developer didn’t make this clear in an easy to find way. He tweeted about it, certainly, but he didn’t announce anywhere easily (logically) located about this.

Now W3TC also fails on one of my critical hallmarks of support: Nowhere in the readme (or on the official WordPress repository page) does he say how to get help. I happen to know that if you want to report a bug, you go to http://yourdomain.com/wp-admin/admin.php?page=w3tc_support and use the form there. He also doesn’t link to his website, or even the plugin page on his website from the repository, nor does he mention that he doesn’t help you configure the site for free.

While I love this program and use it on all my sites but one (at 60 hits a day, it doesn’t need it), I think he’s wrong to not spell out how support works, and he failed to explain what was happening. All we know is he fixed this:

Fixed bug with existing installation upgrades: set minify to manual mode by default

Nothing was clearly documented, nothing was clearly explained, and no one really knew where to go for help, which meant the forums were filled with a lot of angry, ignorant, people, getting no responses from the developer. Simply put, it looks bad, and if people feel that the support is non-existent, they’re going to get angrier, and post things like how you suck and they’re leaving your product, which makes you angry and feel bad, and less inclined to help them at all, the ingrates! It’s a vicious circle, and spirals downhill really fast and segues right into my final point…

They’re not attacking you

Take a deep breath. What I just said about W3TC can very easily sound like an attack. A lot of the time, people will argue they’re not attacking, they’re being passionate, and in the same breath accuse you of being overly defensive. You’re going to, rightly, be defensive and proprietary of your plugin because, as we discussed, it’s yours. You put in the sweat equity, you researched, studied and tested, and you made something awesome. It hurts when people tell you it sucks.

Alas, they’ve forgotten you’re a person too. There isn’t a good/easy way to remind them you should be treated as a human, sadly, so when people start getting fired up and telling you that you suck and the plugin sucks, the best you can do is be the better person. I mentioned before that users are people. This is not a repetition of that fact, but a reminder to yourself that there are days where all this is going to be terrible, awful and you feel like the users have pitchforks and want your head

When this happens, they’re not attacking you. They don’t hate you, they just don’t know how to explain problems without hurting you, because you’re always going to be too close to the problem. I’m willing to bet Bill Gates and Steve Jobs still feel twinges of pain when people rant about their products. Like a parent, you love what you’ve created, and every slight against it feels like fishhooks in your skin. This cannot be avoided, and the best you can do is recognize that they are a little unreasonable, and that your reply is probably a little unreasonable, and stop.

If you can’t address the situation without feeling your skin heat up or your blood pressure rise, walk away for a while. We’ll still be here.

In Summary

I would never say ‘don’t sweat the small stuff, and it’s all small stuff’ or anything trite like that. I will say the point of all this is to be honest, be upfront, be clear and keep it all in perspective. That way you will have both respect and your sanity.

24 May, 2011
WordPress 3.1 and Network Menu
This one’s really fast, but the word should get out there. It’s extremely important if you’ve built a BuddyPress plugin, because the BuddyPress menu has been moved. If you do not do this, your BuddyPress menus will vanish, and you will have very angry users.

WordPress 3.1 has moved the admin menu for MultiSite. Instead of having a Super Admin menu available on the sidebar of your Admin section all the time, there’s a new link in the header bar for Network Admin. Thats right, it’s its own page! The problem with this is that a lot of plugins aren’t ready for that and because of the move, their admin menu links vanished.

Thankfully it’s an easy fix!

The WP Codex Doc on Admin Menus tells us to use “admin_menu” when adding menus. Well, if you want your plugin to show up on the Network Admin page, you have to use “network_admin_menu” instead. (Trac #14435)

See? I said it was easy.
```
add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );
```
There’s on catch to this. What if your plugin is for Multisite and NON MultiSite? Honestly I don’t know if this matters, but just to be safe, I would do this:
```
if ( is_multisite() ) { 
     add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );
} else {
     add_action( 'admin_menu', 'MENU_FUNCTION', ## );
}
```
Or this:
```
     add_action( 'network_admin_menu', 'MENU_FUNCTION', ## );
     add_action( 'admin_menu', 'MENU_FUNCTION', ## );
```
That’s right! If it’s there and not-needed, it does no harm! I’m not 100% certain right now if you need to do this for the non-menu calls people make (like calling a function on admin_menu to check for installation), but I’ve been adding it in to no ill effects. I figure, the BuddyPress core code does it, so it can’t hurt!
27 January, 2011
My plugins are ready for 3.1

I did a quick run through my plugins, and everything is ready for 3.1, even the tricky wicket of Register IP – MultiSite, which is now Version 1.0.

New things:
Register IP – MultiSite works for both 3.0.x and 3.1, single and multisite. The fix put in by the dev team means that the same actions will work for all site types! Yay!

Disabler now lets you disable the 3.1 admin bar (thank you, Ozh!) but NOT as a default option. Remember, Disabler is meant to allow you to pick and choose what you want to disable. If you want a site-wide/mu-plugins type setup, you’ll want to use Ozh’s plugin Disable Admin Bar.

Thoughts:
I’m seriously tempted to ‘sunset’ Recently Registered since it’s fugly and doesn’t work right.

25 November, 2010
Moving Your Images For MultiSite (Updated)
Updated after Andrew Nacin asked me “Why are you suggesting they replace ‘wp-content/blogs.dir/1/files/’ into their post content, instead of /files/?” (Answer: Because when I did this on my first site, about a year ago, I majorly goofed my SQL search/replace and shot myself in the foot For some reason, that made me think ‘files is bad! Blogs.dir is good!’ which … it’s not. Really, blogs.dir is fewer redirects, but that’s really about all I can say. So this has been edited. Thanks!)

In generic WordPress single installs, your images are, by default, located in a folder called uploads off the wp-content folder, and tend to look like this: wp-content/uploads/YYYY/MM/image.jpg. When you use MultiSite WordPress, the files are now in wp-content/blogs.dir/#/files (where the # is the blog number). If you upgrade from Single to MultiSite, you can leave the files for Blog #1, i.e. your primary blog, where they are to no ill effects. Or you can move them.

I’m not going to be using # as a placeholder, as for most people this blog will be 1. If for ANY REASON yours is not, change it.

Also, I can’t stress this enough, you don’t have to do this! Your images will be just fine where they are, but if you want to move them, you can. Enough people have asked on the WordPress.org support forums that I bothered to consolidate my notes on this, however.

Oh, and backup. Always backup before you start this sort of thing, otherwise you’re a reckless fool.

Step 1 – Move the OLD files

This is easy. Copy or move the files to wp-content/blogs.dir/1/files

While you’re in there, remember to set the folder writable so you can update files later. Your images will now look like wp-content/blogs.dir/1/files/YYYY/MM/image.jpg – Make a note of this, you’ll need it in a second.

Step 2 – Teach WordPress where the OLD files are

There are two main ways to do this:

Edit the Database
If you have phpMyAdmin or are savvy at command line SQL, just go ahead and run the replace command:
```
 
update wp_posts set post_content = replace(post_content, 'wp-content/uploads/', 'files/');
```
Now someone here might go “Hang on, I put my files in blogs.dir/1/files and you’re saying to tell WordPress to look in files! What gives?” What gives is what Andrew reminded me! WordPress MultiSite parses files from ‘files.’ The shortest explanation is ‘It’s an .htaccess trick.’ The longer explanation is it’s own blog post.

If you don’t like the idea of SQL, get a search and replace plugin like Search and Replace or Search RegEx and install it. Then search for wp-content/uploads/ and replace with wp-content/files/ to change the database.

In both database cases, you’ll want to check changes all over the place. For wp_posts, check post_excerpt and post_content, and then go through wp_postmeta and edit the meta_value fields.

.htaccess
That’s a lot of work, and odds are you’re still going to miss something. You can also be really lazy and add this to your .htaccess file, before the WordPress stuff:
```
 
# Moved Images
RewriteRule ^wp-content/uploads/(.*)$ http://domain.com/files/$1 [L,R=301]
```
That redirects things quietly. It’s probably not the best way, but like I said, I’m lazy. If I was doing this for a client, I’d probably do both the database fix and the .htaccess, to catch any stragglers.

Step 3 – Tell WordPress where to put the NEW files

Now the fun part! Go to your site’s wp-admin section, click on Super Admin and pick sites from the drop down. Hover your mouse just below the path to your main blog and click on Edit

In that new screen, scroll down and look on the left for Upload Path – You want to change that to wp-content/blogs.dir/1/files

You also want to change Fileupload Url to be http://domain.com/files (this will hold true even if you’re using subfolders or subdomains).

If you see Upload Url Path, you can change if to http://domain.com/files as well, though it appears to be depreciated and no longer used.

Step 4 – There is no Step 4

That’s it! You’re done!
19 July, 2010