Tag: wordpress

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
TimThumb, Heroism and FUD

FUD is “Fear, Uncertainty and Doubt” and it’s a tactic used by people to scare you and make you jump into a decision that benefits them. This decision may not be a bad decision, but it’s not strictly to your own benefit, but theirs. Keep that it mind, it matters.

Recently it was discovered that there was a massive vulnerability in TimThumb (TimThumb is an image editing tool for your webapps). It had an honest-to-god Zero Day Vulnerability. I don’t use the code, and I don’t put it on any site I run, so I knew I was pretty safe. Still, I ran searches for timthumb.php on my entire server, made sure it was clean, and moved on.(Not relevant, I recently changed all my passwords on all my sites, and my servers, because I realized I’d used the same ones for about 6 years.)

The exploit primarily affected WordPress installs, because it was developed for WordPress in the beginning, but since then has grown to be used by many other apps, like Drupal and Joomla and even home-grown ones. It’s insanely cool, but it’s always had weird little problems (which is probably why it’ll never be included in the core code of those apps). Getting it to work at all on MultiSite was a pain, and when someone wrote a how-two, we gave her Tim Thumbs up!(Bad joke. BAD bad bad joke. Sorry.)

Certain people leaped into action. VaultPress, which runs a backup service for WordPress users, sent out emails to everyone who had TimThumb. Then they went the extra mile and fixed 712 possible exploits for you. (I know some people got shirty about it, since they didn’t want VaultPress editing their data. That isn’t the point here.) They jumped up and said ‘We must fix things for people’ and did it. This was, indeed, Matt’s vision for VaultPress.

But then this other thing happened, and I’ll quote Matt:

It could have gone a lot of ways, but the incident brought out the best in the community. The core team sprang into action searching through the theme directory to inoculate any themes that contained the dangerous code. Community blogs quickly got the word out about the problem so people were aware of it. Mark Maunder, who originally discovered and broke down the problem, created a fork of the code called WordThumb that rewrote TimThumb from the ground up. Forking is not usually ideal because it fragments the market for users but Mark soon connected with Ben Gillbanks, long-time WordPress community member, and they’ve teamed forces to release TimThumb 2.0, a collaboration that exemplifies Open Source at its finest. An updated plugin should be in the directory shortly.

Let me explain. There was a problem with a popular tool that is used both in themes and on its own plugin (and probably others). Mark found the problem, fixed it, and then re-wrote the tool. Then, after Matt commented on his site that Forking is a last-resort, even though this was a ground-top rewrite, Mark agreed and talked to the TimThumb guy and together they fixed everything. And now they’re a team. No one made any money off that process. People just did the right thing to make the web safer for all of us! (Okay, that’s not the point either, but it needed to be made.)

All of this was done in a way that the public knew about the problem without getting into an “OMGWTFBBQ!!!11!?” panic. Was there some fear? Yes, because you knew there was a problem and there was a possibility it could affect you. Was there uncertainty? Of course! Again, could it affect you? Was there doubt? And this here is where we have a win for the Open Source community. There wasn’t. It was a straight up ‘This is what’s wrong, this is how to fix it.’

In so many ways, that’s how every business should work. It could have been better, certainly, but when I compare this to how I get security alerts for our servers at work, I see nothing but room for improvement. Right now, one person has the job to look for vulnerabilities that are published about anything we use. If she sees one, she opens a ticket and says ‘Fix this ASAP!’ The problem is, to use a recent example, ownership of the fix. We had a vulnerability with .NET, but as I read the whole doc, I sorted out that it only happened if your server was configured in a certain way so as to make a security hole. Another quick check and I saw the server team had their own ticket ‘Fix this hole.’ So I closed my ticket and said ‘Will be resolved with Server Ticket 1234567.’ My ticket was reopened and I was told I did it wrong. This was a problem with my application (I don’t ‘own’ .NET, I happen to be on the team who brought it into the company, however). I pointed out it wasn’t that .NET was vulnerable, that it was the server. They didn’t care. My ticket has to be open until the problem is resolved, no matter what. In the end, I turned off the feature that might, possibly, be vulnerable and got chaff for not doing it right.

When you compare that to the beautiful simplicity of Open Source communities, it makes you wonder how anything actually gets done? We’re so afraid (fear) of being wrong or doing the right thing without the right approvals, we let the process hamstring us from fixing the problem. We don’t know (uncertainty) what the right thing is anymore, so we do nothing. And in the end, we’re not sure (doubt) if we’re of any use at all. (I think my premature grey came from this job, and if I leave, the first thing I’m doing is dying my hair neon blue.) Plus, to make matters worse, they told the entire company about the security hole, so everyone knows, and they can see we didn’t close the tickets. It’s a mess.

But really that’s not what FUD is about. Nor is it what this post is about. Neither way is perfect, and both are flawed in different ways.

You see, what Open Source nailed in one was that we should be aware of the dangers, and work together to make it better, not feed the fires and run around terrified about what’s going on. A little fear is a good thing. It clears the arteries and is good for your heart. If you’ve never had a moment where the blood drained out of your face because you made a mistake, you’re not trying hard enough. We all live with uncertainty and doubt, too, and inherently these are not bad things. What is wrong is allowing them to have complete control over your actions to the point of inaction or consistently making the wrong choice that you know is wrong.

Make the right choices. If a bread stick is on fire in the toaster, take it out and make that extra step to sort out who put it in there. Treat everyone as a team member, a fellow hero. You see, if we give in to FUD, we cripple ourselves, much like corporate america does every day with miles of red tape. But if we don’t, if we accept our fear and move forward, we can get past it and make better products for everyone. And that’s a great goal.

If you think you, or a friend, may have been hacked, please go to Sucuri and run the free scan for your website.

19 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 (Not) To Ask For Help

I wrote about this once in I’m not a coder and I need help! It’s come up again.

I was a bit torn about posting this, given that it’s a guy acting like a real jerk in public, and I’m still pretty sure his problem is that he doesn’t understand what we’re saying. But. I think it’s good to have a concrete example of how you don’t ask for help on a forum.

The story so far: WordPress 3.2 was released on July 4th, and we knew there would be some minor issues. Most of them are related to the fact that WordPress no longer supports IE 6, PHP4 and MySQL 4. Before it was released, I decided to be proactive and take the lessons learned from 3.1 and make a Troubleshooting Master List. I posted to the forum mailing list and got advice from everyone there. As soon as 3.2 was let loose, I posted and started checking the forums.

Then I found this guy.

Yes, I did get really annoyed/upset with this guy. Full on anger. My face went hot and I felt myself typing furiously. And I deleted what I’d written at least a dozen times in order to keep as cool as I could. I knew I was mad, I knew I was writing in anger, and I backed away. That’s why my replies got shorter and shorter until, finally, I walked away and let the rest of the community hit him with a brick. I did come back the next morning and close the post, but only because it had become impossible to help the guy. And yes, I would have left it open to help him. It’s what I do.

So taking the cue from his post, let’s run down the ‘what NOT to dos.’

Cursing

The actual title of his post is Upgrade to V3.2 and my site is f**ked. Except he said ‘fucked’ but we modified that. The URL still says it. Just don’t do that. It’s rude. If I have to explain why it’s rude, you need more help than I can give. And I say this from the point of view of a foul mouthed tart. There is a time and place to swear, and the free support forums ain’t them.

Mouthing off

Even if you’re not swearing, there’s a huge difference between being polite and being a cretin. People are taking time out of their day to help you. Treating them like they’re worthless and insulting them is not a good thing to do. Being polite, even when you’re very angry and upset, is hard. I’m aware of this. But that doesn’t excuse your behavior. You’re the one who decided to show your fanny. It’s like what they say on Reality TV. The people being filmed will blame the editing, and the editors will point out ‘We didn’t MAKE you pee on Joe Bob there, you did that on your own.’ Yes, selective quoting and editing can make you look worse, but frankly, you’re the one who put it out there.

Not taking the time to read

I think this falls under ‘Not taking the time to think.’ We told the guy multiple times ‘You need to reset your plugins.’ We linked him, multiple times, to directions on how to do that when you can’t log into your back end. Three times he complained that he couldn’t get to the back end of his site before he finally up and said he wasn’t going to.

Most of the issue was that while we told him what to do, he was blinded by his own interpretation of what we meant. He would have been better served by simply saying ‘I don’t understand what you mean by FTP’ … except he did.

Not following directions

This is really simple. If you’re asking for help, you’re assuming the people who answer know more than you. If you refuse to follow their advice, you’re done. Seriously.

Getting derailed

You may have noticed how he started picking on my language (I used ‘seriously’ twice, and apparently that was too many times), my nationalism (I’m a dual-citizen as it happens), politics (Afghanistan), and so on and so forth. A lot of energy was wasted by his anger and the resulting attitude from it.

The entire reason I did not snap back and point out where his gross assumptions were wrong is because it was not productive. It would just make him madder (yeah, think about that for a second) and make the situation more volatile. Don’t feed the fire.

It’s NOT all about you

I cannot stress this enough, every single volunteer on the WP forums knows and understands exactly how important your site is to you. I have this problem in my day job too. I work with hundreds of very important people (they actually are – the office would come to a standstill if any one of them broke). They are all incapable of understanding that everyone is just as important as they are. I have been known to snap at people and point out that more than one VIP is having a problem, and I am working on the issue, but if you’d like to tell them that YOU are more important, go for it.

No one ever does. They usually shut up, which tells me that really they’re like a kid who fell down on his tush. He’s fine, just crying for effect. You may think that the squeaky wheel gets the oil, but you forget about the boy who cried wolf. At a certain point, we stop listening to you until you come in with a broken wheel.

What else?

Obviously this list can’t be exhaustive (I’d run out of internet before I ran out of examples). The real basic rule is ‘Don’t be a dick.’ Everything else is an extension of that.

If you’re helping someone who treats you like crap, you’re allowed to walk away. At work or at play, you don’t have to deal with it. Just walk away. Of course, at work, you need to tell your boss, and on the WP forums, I tend to email or ask people directly to step up for me please and thank you. In fact, watching the community get my back in that post was both pleasing and very sad. I was sad it had to happen, and I remain sad that he couldn’t be helped.

5 July, 2011
WordPress: Change HTML Editor Font
Starting with 3.2, the WordPress HTML editor has become MonoSpaced. Yay! Problem is that it looks best on a non-Windows PC, so someone of my friends who happen to be Windows users have the grumpy.

I made an htmleditor.php file and tossed it into my mu-plugins folder. You can use the folder in single and multisite WordPress, and it makes any php files in there act similar to your functions.php. I find it preferable since you don’t have to port to a new theme, should you change it. Read What is the MU-PLUGINS folder? if you need more help.
```
<?php
/*
Plugin Name: HTML Editor
Plugin URI:  https://halfelf.org/hacks/wordpress-html-editor-font/
Description: I don't like the HTML editor Font on Windows
Version: 1.0
Author: MA Epstein
Author URI: https://ipstenu.org/
*/

function html_editor_admin() {
        ?>
        <style type="text/css">#content #editor, #editorcontainer #content, #editorcontainer textarea#content, #editorcontainer textarea, div#postdivrich.postarea #editorcontainer textarea#content { font: normal 13px/1.5 verdana !important; }</style>
<?php }

add_action('admin_head', 'html_editor_admin');
?>
```
You can obviously change font: normal 12px/1.5 Monaco, monospace !important; to whatever you like.

Enjoy!
28 June, 2011
Manually Customizing the WordPress Admin Bar
FYI – In WordPress 3.3 the Admin Bar was renamed the Toolbar, replacing the header entirely, and now has more hooks to edit it. Please read http://wpdevel.wordpress.com/2011/12/07/admin-bar-api-changes-in-3-3/ for more information.

Since WordPress 3.1, the Admin Bar has been around and been somewhat controversial. Some people love it, some hate it, and some couldn’t care. A lot of the time in the WP Support Forums I had to remind people that you can turn this off for yourself in your profile.

My standard replies to people was pretty much this:
If it’s throwing your theme out of whack, make sure you have a call to wp_footer() in your theme’s footer. The next cause for that is your theme’s css having a conflict. If it’s your avatar size, again, that’s CSS. Wanna turn the admin menu ON for EVERYONE? Use the Always Show Admin Bar Function. Like the bar but not the search? Hide Admin Bar Search Plugin is there. Want to minimise it? Admin Bar Minimiser Plugin. Want to disable it selectively? Admin Bar Disabler Plugin can do that.

Finally if you MUST turn it off… you can add one of these to your functions.php
```
add_filter( 'show_admin_bar', '__return_false' );
show_admin_bar(false);
show_admin_bar(0);
```
OR use the Disable Admin Bar plugin.

FYI, if you put the plugin in a folder called mu-plugins (yes, you can do this on Single Site as well as MultiSite) then your users won’t be able to un-install it unless they go in via FTP. Just put the mu-plugins folder in the same level as themes and plugins (wp-content/mu-plugins) and copy the FILE (not the folder) for the plugin into there. Done.
Now me? I like having it on. I used to have it turned one for all users, all visitors, everyone all the time. Recently, when I re-designed some sites, I removed that functionality because it was showing too much info to people who were suffering from information overload. Once I pulled the admin bar off for non-logged in users, I realized I wanted to change the way it worked.

The normal admin bar is actually pretty straight forward. The pretty icon of your user ID with a drop down menu rocks. The problem I had was my site was built to keep people off the backend. I already use the rocking WP Hide Dashboard plugin, and BuddyPress is installed, so I wanted to redirect people from places like ‘My Profile’ on the unbranded WP backend to the pretty BuddyPress front end. And yes, I think all ‘user interface’ plugins should have a front-end version.

I could have used something like WP Custom Admin Bar, but I knew I was going to want some pretty weird, granular level, control over the layout and the submenus. In order to make this look how I wanted, I had to remove menus I didn’t want (or need) and add in new ones. I did it all in a file called adminbar.php, which I tossed in the mu-plugins folder (so on a multisite it can never be turned off):
```
function ipstenu_admin_bar_remove() {
        global $wp_admin_bar;

        /* Remove their stuff */
        $wp_admin_bar->remove_menu('my-blogs');
        $wp_admin_bar->remove_menu('my-account-with-avatar');
        $wp_admin_bar->remove_menu('appearance');
}

add_action('wp_before_admin_bar_render', 'ipstenu_admin_bar_remove', 0);
```
The values like my-blogs and so on are the IDs of the menus you want to yank:
- my-account-with-avatar / my-account: Links to your account. The ID depends upon if you have avatars enabled or not.
- my-blogs: My Sites menu. For networks (aka MultiSite) only
- edit: Post/Page edit link
- new-content: Add New Content menu
- comments: Comments link
- appearance: Appearance menu
- updates: Updates link
- get-shortlink: Shortlink to a page
While some of these menus only show up for the admins, I figured I may as well remove the ones I don’t need right there anyway. I’m also of the (unproven) opinion that the fewer calls I make in that admin menu, the faster my site will be. The only reason I yanked my-account-with-avatar was because I wanted to remove some of the submenus and add in my own. I found it was easier to recreate it on my own, so I did this:
```
function ipstenu_admin_bar_add() {
        global $wp_admin_bar, $user_identity;
        $user_id = get_current_user_id();

        /* Add my stuff */
        if ( 0 != $user_id ) {
                $avatar = get_avatar( get_current_user_id(), 16 );
                $id = ( ! empty( $avatar ) ) ? 'ipstenu-account-with-avatar' : 'ipstenu-account';
                $wp_admin_bar->add_menu( array( 'id' => $id, 'title' => $avatar . $user_identity,  'href' => 'https://ipstenu.org/members/'. $user_identity .'/profile/' ) );
                $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Edit My Profile' ), 'href' => 'https://ipstenu.org/members/'. $user_identity .'/profile/edit/' ) );
                if ( current_user_can('manage_options') ) {
                        $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Dashboard' ), 'href' => 'https://ipstenu.org/wp-admin/' ) );
                        $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( 'Network Admin' ), 'href' => 'https://ipstenu.org/wp-admin/network' ) );
                }
                $wp_admin_bar->add_menu( array( 'parent' => $id, 'title' => __( '<strong>Log Out</strong>' ), 'href' => wp_logout_url() ) );
        }
}

add_action( 'admin_bar_menu', 'ipstenu_admin_bar_add', 10 );
```
But wait! If you just tried that, you found out the CSS looks like a monkey puked on your site. The avatar icon’s goobered, that pretty sprite that shows the arrow is missing. Well, that’s easily fixed with some CSS.

In the same adminbar.php file, I put this:

function link_to_stylesheet() {
if ( is_user_logged_in() ) {
?>

wp_head you still get the fugly on the admin side. That’s easilly fixed with a second action call: add_action('admin_head', 'link_to_stylesheet');

Now you can make your admin bar have the menus (or submenus) you want to your heart’s content too!

While you can take my work for your starting point, here are the links I found helpful when I was kicking all this around:

• SumTips: Customize WordPress Admin Bar by Adding/Removing Links
• WP Engineer: Add Menus to the Admin Bar of WordPress
• Digging Into WordPress: Admin Bar Tricks
23 June, 2011