Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: freedom

  • Plugin Licenses, Upsells, and Add-ons

    Plugin Licenses, Upsells, and Add-ons

    This post is dedicated to WPEngine, who donated to help me get to WCSF. While I don’t use them, I think that if you’ve outgrown WordPress.com and aren’t quite ready to host everything yourself, but you still want the plugins and themes, then you should check these guys out. They aren’t cheap, but then again, I firmly believe in paying for what’s important.

    Read the comments before you comment. Otto haz the smartz.

    Phone HomeOne of the many rules of WordPress.org hosted plugins is you can’t phone home. Actually you can, and the rule really is ‘Don’t phone home without a damn good reason.’ To use Akismet as an example, it phones home with information to help verify who posted on your site, and are they a damn dirty spammer. That’s a damn good reason. But phoning home to check “Did Bob pay for a license?” is not. That’s considered abuse of the “serviceware” guideline, and essentially making an API just to make sure a license is okay isn’t okay. Now making money on your plugins is an awesome thing. But when your code is open source and anyone can see it, how do you keep people honest?

    To get down to brass tacks, I’m going to take a little jounrey the wrong way, before I get to some suggestions on how you can provide ‘free’ and ‘pay’ versions of a plugin on the WordPress repository, and not cause any guideline issues.

    Let’s start out with the most common way people restrict you: A license key. If you put in a plain license key check like this, it’s easy to crack:

    if ( $license == "yes" ) { // Licensed! }

    Okay, you say, I want to encrypt things so that I tell someone ‘your license is ipstenuisreallyneatsheismadeofturtlemeat’ but when I look at my code, it shows ‘774ffc4efce8da294dff77f35f75df98‘ instead (that’s md5(ipstenuisreallyneatsheismadeofturtlemeat) as it happens). Wait. We can’t encrpyt code. Or rather, we can’t include encrypted code in a plugin, it’s against the no-obfuscation rule. We’d want to decrypt that instead. So I give you the code string instead and run it this way instead (Just pretend that $options['license'] is a site option.):

    if ( md5(ipstenuisreallyneatsheismadeofturtlemeat) == $options['license'] ) { // Licensed! }
    

    But then I have the problem of anyone can just look and see what’s going on again. You could go the extra step like putting ipstenuisreallyneatsheismadeofturtlemeat in a file and then pull off something like this:

    $md5file = file_get_contents("md5file.txt");
    if (md5_file("test.txt") == $options['license'] )
    

    No LicenseIs this easily decrypted? Yes. Is this easily circumvented by editing the code and removing the if? Again, yes. In fact the only way to really do this would be to use an API on your server to check the validity of the license (which you can’t do if you want to be hosted on WordPress.org anyway – no APIs just to check licenses), and even then I can strip mine your plugin and remove all checks like that. So why bother? Because you want to make a living on your code, and that’s certainly a fair-go! But as Otto rightly says, we can’t stop piracy, so why are we trying? DRM doesn’t work, and reverse engineering hasn’t proven sustainable. Maybe we’re building the wrong mousetrap.

    If we throw the code solutions out the window, because we know they won’t work, where are we left? The next most common thing I see is people offering two plugins. A free, totally open GPL one on the WordPress repository and then a version behind a pay-wall that you would ‘replace’ that free one with. For example, I have a Rickroll plugin, and let’s say I wanted to make a Rickroll Pro version that let you change the video to anything you want, just put in the YouTube URL. I would have a settings page on my free version that pretty much says “Hi, if you want to change the video, visit halfelf.org/plugins/rickroll-pro/ to download.” And now I have to code Rickroll Pro to check if Rickroll (free) is installed and active, and refuse to activate if so. Furthermore, my users have to be told to delete the free Rickroll.

    You know what? That’s a pain in the butt. What if instead I coded a Rickroll Pro add-on. No, I don’t mean ‘add this file to your plugin’ but ‘Install this second plugin, which will add functionality to Rickroll.’

    It’s a second plugin, yes, but now I can have Rickroll free look for Rickroll pro. Not active? The settings page (which I would keep in Rickroll free) would tell you ‘Hey, you don’t have Rickroll pro! Install it and get more things!’ or ‘Hi, you have Rickroll pro installed by not active. Don’t you know it’ll never give you up? Activate it and have fun!’

    Now the code muscle becomes a question of ‘How do I ensure my dependency checks work?’ First, Scribu wrote an awesome plugin dependency plugin, and the only flaw with it, is you’d have to install a third plugin. We don’t want that here, since yet another plugin is problematic. But looking back, that code grew out of a trac ticket about handling plugin dependencies. Now there’s a nice way to check: is_plugin_active()

    if (!is_plugin_active('rickroll/rickroll.php')) {
        // do not activate. Provide message why.
    }
    

    ProtectedYou could go to town with the checks in there. Like if the plugin isn’t active, deactivate the child and so on and so forth. I’m not going to write it all for you (though Otto wrote a lot about it for themes)

    Now going back in your parent plugin, you can run the same check:

    if (!is_plugin_active('rickroll-pro/rickroll.php')) {
        // Rickroll pro isn't active, prompt the user to buy it.
    } else {
       // Include rickroll-pro/adminsettings.php so they can use it
    }
    

    The one last thought I had on this was how to handle pro upgrades. Since I don’t like to upgrade a plugin a lot unless I have to, I’d make it an ‘upgrade both’. In Rickroll Pro I’d set a version constant, and then in that check to see if it’s active call, reference that version. So Rickroll, after verifying Rickroll Pro is active, would come back and say ‘My current supported version of Rickroll Pro is 1.5 and the constant is set to 1.0. You should upgrade!’ Then every time I write a new version of Rickroll Pro, I’d update Rickroll to point to the new version, and when they upgrade from WP, they would get notified about Rickroll Pro needing an update too.

    Probably not the most efficient or effective way about it, but the other option is a self hosted plugin update API.

    Bear in mind, because of GPL, all these hoops and ladders can be circumvented. Your plugin can and will be taken away for free. Don’t fight the pirates with registration circuses, and limit the weight of your code by selling the right thing. It’s a strange idea to think that giving your code away for free will help you earn money, but at the very least, not fighting against the pirates will give you time to write better, more secure, code. And that certainly will earn you more money. Then sell your support, because that time is money.

  • You Can’t Be Everything

    You Can’t Be Everything

    There’s no app out there that does everything.

    A lot of you just said ‘I know.’ but did you ever stop to think about why that’s the case? After all, some applications do everything you need them to do, and some you don’t, so who gets to decide what is and isn’t needed? When I talked about how WordPress was just fine on it’s own, without any plugins, people stepped up and said “But Ipstenu, I really need XYZ.” Heck, Lorelle said she needed Akismet.

    Learning how to separate your personal needs from the needs of the masses, when writing software, is a full-time job, and many of us come at it from a slant-wise point of view. In fact, writing core code for WordPress is in diametric opposition to why we write plugins! While I’m going to talk about it from a WordPress point of view, the concept holds true to any application that has ‘add ons.’

    Plugins are written, by in large, to solve a specific problem. They’re not ‘fixing’ WordPress, they’re expanding. Remember, your iPhone wasn’t broken until it had Angry Birds, nor was your iPad incomplete without Twitter. Those are things you wanted, and solved a problem for you. The base tools, in and of themselves, address a broader group of people, with a diverse set of needs, and have the option of being everything or nothing.

    The best tool, WordPress, your computer, etc, are built to be extendable. They’re built with the innate knowledge that the users may want things they can’t forsee. Five years ago, how many of you thought Google+ or Twitter would be a ‘thing’?  Let’s take that further. You know how when a new video game comes out, sometimes you can’t play it on your older computer? That’s because it wasn’t built with the new game in mind, so it’s just not capable. And that’s why computers generally let you upgrade memory, CPU, and hard drives. They are built to be extendable becuase they know they can’t know the future.

    Bringing it back to WordPress, it was built to meet a need. People wanted to blog, they wanted it to be easy and they wanted it to just bloody work! So the Matts said ‘This is what we want’ and built it. Thankfully, they understood that people wanted to extend WordPress. But not at first. Oh you didn’t know? Back in December 2003, a ‘new feature’ was introduced called my-hacks.php, which let you put a file by that name in the root of WP, and it would treat it like a functions file. In fact, that’s why I call my non-plugin code ‘hacks.’ Heck, we didn’t get pretty permalinks until January 2004 (then called ‘cruft free’ URLs).

    The point of this is not to expose the funny looking beginnings, but to demonstrate the nature of the software. As it grew, people had needs, and instead of writing everything into core, they cleverly changed WordPress so it was extendable and let people grow as they needed. So when we talk about things like needs and wants, we do it in the understanding that we write our software to fill a need, and we make add-ons to fill wants. Sounds like double speak, I know, but that’s why I said plugins and core development are in direct opposition.

    When I want to add things to core, I want them to be useful to everyone, so I’m forced to remove my ego from the equation. Looking at the (few) core submissions I’ve made, I carefully thought them out beforehand. I looked at places were the user experience was inconsistent or diminished. When I make suggestions or offer commentary to what I think could be better, I try to show my passion without acting like a teenager’s first big crush, or a screaming fangirl meeting her heroes.

    This isn’t to say I don’t think passion is a part of the driving force of any product, but that it must be tempered and controlled in things like WordPress core. We know that we can’t make WordPress core do everything, and we know we shouldn’t. When things are extendable, we utilize that and demonstrate our fire. When they’re difficult to extend, or kludgy to implement, we come back and say ‘You know, it would be nice if we could…’ But at the end of the day, when WordPress tags your trac ticket ‘wontfix,’ it’s because they know, being unable to be all things, that they must limit the things they are.

    If you haven’t yet, take the time to read WordPress’s Philosophy.

    Aaron Jorbin - Haters Gonna HateWhen I usually talk about divorcing my ego from a project, what I mean is that I don’t let my passion cloud my better judgement. One of the lessons I’ve learned in nearly 20 years of active fandom is that when you love something, you get fired up about it, and you tend to view peoples opinions and actions as a personal attack when, in fact, they often aren’t. Yes, there are idiots and trolls and people who hate-monger, but in general, people actually aren’t dicks. They’re selfish and self-centered, but that’s just human nature. Part of designing a project means you have to let go of your personal attachment to your baby, and understand that haters are just gonna hate, and there’s nothing you can do about it.

    This also applies to using a tool, though. People mock the evangelists, and we all hate the extremists, and certainly no one actually supports those who are outright malicious. But all those archtypes come part and parcel with a system, and are all aspects of the simple problem that no one product can do all the things. We want things to be a silver bullet, to fix everything we, personally, have a problem with, and we’re totally unrealistic in wanting that.

    Mark and I were talking recently, and he pointed out that WordPress was once 230kb. It’s now 3.8megs, even zipped up. Part of this is because it all grew and became more, but if you ask the old-timers, some will complain that around the 1.5 days, WordPress just became too big. It does too much! And those people say we should pull things like the importer out of WordPress. After all, you’re going to use it once, if at all. Core plugins would get pretty big too. Jetpack is 2.4megs on its own, zipped up. By trying to be everything, maybe we’re making things a little worse.

    So the next time someone gets their panties in a bunch at you for not doing everything, tell that it’s by design. Do what you want with your code, make it easily extendable for the next guy (or forkable), and carry on. They’re not getting that unicorn.

  • Fork With Restraint

    Fork With Restraint

    I love that the GPL lets you fork. In fact, two of my plugins are forks and one’s an adoption. I think that’s one of the best things about GPL, the freedom to adapt and move on. But every single time you fork a plugin, you cause a couple problems that many people are either ignorant of or just don’t care about.

    Confusion

    If you look up ‘WP Grins’ there are three plugins. ‘WP Grins’ is the original, ‘WP Grins Lite’ is the first fork, and ‘WP Grins SSL’ is the third. Each one is pretty explanatory. The plugins are similar, but you get the idea from the title what’s different. And in each case, each forker took the time to say ‘this is what’s different’ in obvious ways, and to credit those who came before. This is important because, based on name alone, there’s not a whole lot to differentiate the plugins.

    Multiple ‘things’ with the same name is confusing. That’s really very obvious isn’t it? That’s why companies spend hours and months fighting to protect their trademarked names. The name of a ‘thing’ is important, and the difference between the names is the crux of everything. In a predominantly text world, your name is everything.

    Bad Feelings

    This is where it gets weird. As you all know, I’m a huge supporter of forking. But sometimes when you fork, you’re a dick. There are a lot of weird things to consider when you fork, and for me, the first one is ‘Is the plugin I’m forking something you pay for?’ Generally speaking, if I’m even considering forking a for-pay plugin, I’ll try to start up a dialogue with the developers first, because I know that these people are trying to make a living, and I’m a dick if I take that away from them. Yes, GPL says I can do it anyway, but there’s the law and then there’s the community.

    A lot of the time we tout the ‘spirt’ of GPL and I really hate that. We’re actually touting the cohesiveness of the community. That we know plugins are often free, but pay for support, or behind a pay wall, or a million other things. But. If you take away someone’s ability to make a living, you are a raging dick.

    Strong words, but ones I firmly believe in. It’s no secret I’m not fond of the IncSub folks and their behind-a-paywall/yearly fee for plugins. My issue isn’t their code, however, or their prices, but their attitude. And while I don’t like them, I will support till my dying day their right to do it. And if someone logs in to their site, gets an account, downloads everything and then puts it up on their own site, well, I’ll support IncSub in kicking them while they’re down, because it’s just not nice.(This actually happened in November 2011.)

    As Jane Wells put it:

    The GPL does allow for redistribution of GPL code. You can even charge for it if you like. However, here at WordPress.org that sort of behavior is not encouraged or supported in our repo. If you redistribute, we expect to see modifications not available in the original. We show respect for the authors of GPL code by only promoting redistributions that are useful as new contributions through helpful modifications.

    Which is why, when I forked the plugins I did, I made clear changes. Works on SSL now! Works on Multisite! And none were pay-for.

    But what does ‘being nice’ have to do with this?

    It Pays to Be Nice

    WordPress’s strength is their community. It’s the people who dream and invent, and the GPL has given those people tremendous amounts of freedom to be creative and expressive. Where WordPress runs into problem is personality conflicts and clashes (even the smartest people can be assholes). And where you will see the most of those conflicts and clashes is when it comes to GPL and who has the ‘right’ to do whatever. (Second only to GPL is SEO.) Once you incur the ire of a community, your ‘cred’ drops amazingly. That’s why so many of us are accused of ‘drinking the Kool-Aid’ when we tout the GPL party line.

    A quote in my comment ‘guidelines’ is from Lord Buckley, “If you know what to do and you don’t do it, there you bloody well are, aren’t you?” We all know the right things to do are to be good people. To respect each other and treat our fellow man with kindness. I don’t care what religion you are, or even if you worship the FSM. The only way we all get through this thing called life is to be decent people. Taking away someone’s source of income is rarely nice, and when you do it and say ‘I did this because it’s GPL and I can!’ then you’ve done it for the wrong reasons. Just because you can do something doesn’t mean you should. We all learned that as children, that just because I can throw a rock at Timmy’s head doesn’t mean I should.

    Theft

    When we get to college, many of us experiment, for the first time, with being able to walk away from things we don’t want to do, even though we should (like your classes). And many times, these young adult challenges, where we do the wrong thing, come with no serious repercussions, and we determine that it’s okay to break some rules. This curious attitude follows us into adult life. It’s okay to steal cable/music/movies because the companies that provide them make a lot of money, and the artist never sees it anyway, so we’re not hurting the people who really matter.

    Taking someone’s product that is for sale, making a change and giving it away, is perfectly acceptable in the GPL. But that doesn’t make it right. That makes it legalized theft, and it will hurt your standing in the community. And that’s what people mean by the ‘spirit’ of GPL. You and me and everyone else who writes code or contributes are the spirit of GPL. And when you hurt one of us, you hurt us all.

    Go ahead and fork plugins, it’s what makes WordPress, and any GPL product great. But when you fork, do it for the right reasons, and remember that the developer you’re forking from is a person too.

    Treat them how you’d like to be treated.

  • SOPA Blackout

    SOPA Blackout

    I’m lazy and I don’t want to write a plugin, so I asked on Twitter if someone had one to black out a site for SOPA on the 18th of January. If you don’t get why this is a thing, please read WordPress.org’s post on SOPA. A lot of sites are going black from 8am to 8pm. I am, and I to didn’t want to use a plugin.

    My solution for this involves two files and is all thanks to Pete!

    To do this is really simple. Go in and make a file called .maintenance in the top level of your WP install. For most people, it’s the same folder as your .htaccess and wp-config.php files.

    Now edit that file and put in the following content:

    <?php
     
    // Let's make sure you're not an admin/logged in!
     
    function is_user_logged_in() {
        $loggedin = false;
        foreach ( (array) $_COOKIE as $cookie => $value ) {
            if ( stristr($cookie, 'wordpress_logged_in_') )
                $loggedin = true;
        }
        return $loggedin;
    }
     
    if ( ! stristr($_SERVER['REQUEST_URI'], '/wp-admin') &amp;&amp; ! stristr($_SERVER['REQUEST_URI'], '/wp-login.php') &amp;&amp; ! is_user_logged_in() )
     
    // If it's after 8:00:00 on the 18th, we're going to show the blackout page
     
    if ( time() >= mktime(8,0,0,1,18,2012) ) {
    	// When we hit 8pm (20), we're back.
    	$upgrading = mktime(20,0,0,1,18,2012);
    }
    ?>
    

    What does this do? It’s pretty simple. First it checks to see if you’re logged in and, if so, lets you get where you need to go. If you’re not logged in, though, it checks the date and if it’s after 8am on the 18th, you get a maintenance page. After 8pm on the 18th, it swings back. (All this code, except for the date stuff which I wrote, is from Matt (Sivel):
    WordPress Maintenance Mode Without a Plugin and WordPress Maintenance Mode Without a Plugin Part 3/ ) Pretty cool right? And the 8am to 8pm is based on your server’s time, so it’s all local. It’s also pretty easy to see how you change that for your own time. I would say pick your busiest time to go black.

    But if you want it to look pretty, you need to do a little extra. (Code from WordPress Maintenance Mode Without a Plugin Part 2 and text from Blaccupy) Make a file called maintenance.php and put it in your wp-content folder. Here’s an example:

    <?php
    /* Tell search engines that the site is temporarily unavilable */
    $protocol = $_SERVER&#91;"SERVER_PROTOCOL"&#93;;
    if ( 'HTTP/1.1' != $protocol &amp;&amp; 'HTTP/1.0' != $protocol ) $protocol = 'HTTP/1.0';
    header( "$protocol 503 Service Unavailable", true, 503 );
    header( 'Content-Type: text/html; charset=utf-8' );
    ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
    <head>
            <title>BLACKED OUT</title>
            <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
            <style type="text/css">
            body {
                    background: black;
                    text-align:center;
                    color: #eee;
                    font-family: Helvetica;
                    font-size: 2.2em;
                    }
            </style>
    </head>
    <body>
    
    <div style="width: 960px; margin: 0 auto;">
    <h2>This website is..</h2>
    
    <h1>BLACKED OUT!</h1>
    
    <p>In protest of pending US legislation, which threatens the freedoms of websites like this one and the freedoms of the people who use them, this website is offline on January 18th, 2012 from 8am to 8pm EST.</p>
    
    <p>Please <a href="http://americancensorship.org/">help protect our free speech</a> against the corporate and political interests which seek to take them away!</p>
    
    <p>(And don't worry, we'll be back in business tomorrow!)</p>
    </div>
    
    <?php
    die();
    ?>
    

    Which means your site will look like this on January 18th. You’ll notice I made some tweaks on mine. This is a default feature of WordPress, by the way. You can design your own maintenance mode page just with this one file, so y’know, party time.

    Now there’s only one catch. If you update WP via the automatic updater between now and then, you lose the .maintenance file. I don’t have a fix for that, but if you do, please comment!

    And yes, my sites are going dark on the 18th.

    ETA: If you have a Multisite and only want SOME sites dark, use Customize the Suspended blog page from WordPress Must-Use Tutorials. Suspend the sites and boom goes the dynamite.

    ETA 2: If you’re using MediaWiki (like I am on another site) I came up with this idea to go dark for SOPA. Its just a normal extension that, between those hours, redirects to the same page I use for WordPress. You could have it point to any page, of course.

    <?php
    
    if ( !defined( 'MEDIAWIKI' ) ) die();
    
    if ( time() >= mktime(8,0,0,1,18,2012)  &amp;&amp; time() <= mktime(20,0,0,1,18,2012) ) {
         
            include('/location-of/wp-content/maintenance.php');
        exit();
    }
    ?>

    That code, sans the Mediawiki line, will also work as an extension for ZenPhoto, so pass it on.

  • WordPress › Help Stop SOPA/PIPA

    We are not a small group. More than 60 million people use WordPress — it’s said to power about 15% of the web. We can make an impact, and you can be an agent of change. Go to Stop American Censorship for more information and a bunch of ways you can take action quickly, easily, and painlessly. The Senate votes in two weeks, and we need to help at least 41 more senators see reason before then. Please. Make your voice heard.

    via WordPress › Help Stop SOPA/PIPA.

  • Stop SOPA And Change Your Registrar

    Stop SOPA And Change Your Registrar

    If you have no idea what’s wrong with SOPA, just Google it.

    GoDaddy, a pretty well known domain registrar, not only supports SOPA but helped write it. While in recent days they’d stepped back, it got me thinking. I left GoDaddy years ago, when one of my domains was almost up for renewal. I switched it to NetworkSolutions, which was where my other two domains were.

    History. When I first purchased ipstenu.org (08-Sep-1999 00:09:50 UTC) we got domains by filling out a web form, getting an email with a PDF, printing it up, singing it, photocopying our drivers license and faxing that back in. Then, if you didn’t actually have a drivers license, you got a phone call and a fun chat with a woman about what was going on, yes, the state ID was fine, the domain will be set up in five days. A year later I bought another domain, and since I had an account with NetSol, it was as simple as ‘I want that one,’ and I was done.

    When I got my third domain, I used GoDaddy since it was cheap, easy and fast. Click, click done. In 2008 or so, all the news about GoDaddy’s rampant sexism and general asshattery ended up with me transferring off GoDaddy and onto NetworkSolutions. Except I didn’t. I had a friend do it, since he and I were trading favors. So up until December 27th, 2011, I’d never actually transferred a domain name!

    It’s still weird, and reminds me of the fax days, but it’s pretty easy.

    It’s not that I was having any issues with NetworkSolutions. But their statement on SOPA, while anti-SOPA, still sat in my craw a little. Basically they were chickening out, and while I was pretty sure my domains were fine (and my relationship with NetSol), it was one of those days when I felt like I needed to make a change.

    Namecheap has been on my radar for years. I’ve had an account with them, and no domains, for most of 2011, since the last time GoDaddy got stupid. See, I raise a lot of money for charity, and one of the things I raise money for is elephants. I want them out of zoos and I want them out of circuses. So when I saw GoDaddy’s founder hunted elephants, I had no choice. I couldn’t be a hypocrite and I had to turn my back on GoDaddy. When I decided I should move from NetSol to someone a little friendlier, whom I felt I trusted as people (that’s a huge deciding factor for me) and who had a good rep, I decided to turn to the people taking ruthless advantage of GoDaddy.

    Like Namecheap.

    See, they hate SOPA. A lot. Enough that between the $20 credit I had from them (for playing Internet games) and the $7 SOPASucks discount they were offering, it would cost me a grand total of $1.01 to move my domains over. The only time I’d ever worry about moving my domain names is if my DNS (i.e. the nameservers) were run by them. They’re not, they’re run by me, which means a transfer like this is all paperwork. No downtime, nothing to fuss about except the waiting.

    All the politics aside, if you have no problems with where you registered your domain, and can do everything you want, then there’s no reason to move. I mean that sincerely. I feel that way about webhosts, and all things computer related. If there’s no compelling case for you to move, stay. If there is, though, moving your domain registrar is actually a lot less scary than moving hosts!

    There are a few rules about moving domains. Like you can’t make a bunch of edits to your registry info and then move (it looks ‘suspicious’), and there are date ‘blocks’ on certain things that make you wait 45 days. But assuming, like me, you’ve had the same registrar since the dawn of dinosaurs…

    Step 1) Turn off domain protection from your existing host.

    Makes sense, you’re now setting it up for people to ask if they can have your domain. In the case of NetworkSolutions, you have to check a box to get an EPP Key (Authorization Key). Save that Key, you’ll need it in a minute.

    Step 2) Turn off any WHOIS protection you have.

    If the transfer company can’t see who you are, they can’t add you.

    Step 3) Go and request the domains be transferred over at your new registrar.

    Dead simple. You add the domains, the new guys send an email. You read the email, visit the webpage and click “Yes, please. I want you to be my boss.” This is ‘Fax Number 1’ in the old day.

    Then you get another email, this time it’s the old domain register. “Oh noez! Why you leave me?” they wail. Or rather ‘Are you sure?’ Click yes again. This is Fax Number 2.

    Step 4) Wait up to 5 days.

    And write a blog post.

    My move isn’t done yet, but it’s ‘in transfer.’ While I understand why we have the back and forth’s of the emails (faxes) to make sure I’m really me and I really requested this (remember, I work at a bank in my day job), it’s still odd that after the approval is done, it’s a 5-day wait.

    But there you are. That’s how (and why) you should switch your registrar.