Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: essay

  • The Legality of Forking

    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.

  • Social Media Gets It Backwards

    Social Media Gets It Backwards

    If you’re on Google+, you know you can sort people by circles. I want to tell my ‘Clients from Hell’ people stories about this, or my ‘WordPress’ people stories about that. But what they don’t have is a way for me to say ‘I only want to see Otto’s WordPress stories.’

    I know, that sounds really basic and simple. Public shared circles.

    Circles are a way for me to target you, but not helpful when I want to be selective. So far, no social media product has addressed this. With a blog, I can follow a specific category or tag via RSS. Provided you’re not being a jerk about things, any site using WordPress has the ability to follow a tag or category. https://halfelf.org/tag/wp/feed will show you all my WordPress posts. (However. Many people are assholes and redirect all their feeds to one location, usually FeedBurner, in the interest of getting advertising revenue. http://freelanceswitch.com/, I’m looking at you, and it was a dick move that made me stop following your site.) While this relies on my personal honesty and accuracy, it makes things easier for the reader to find what they want. You can follow the same logic on Drupal via their nodes, WordPress’s CPTS and so on and so forth.

    So why is something that simple and obvious hard to manage on a social site?

    It’s a numbers game. Your site, you’re in control of how you tag and categorize things. I do it differently from many people, who do it differently from others and so on and so forth. While this difference is great (go diversity!) it means that ‘tagging’ a topic on Google is up to the person making the post. I may call it WordPress, you may use WP, and now which one do I follow?

    The best solution I’ve come up with is that when you add someone to a Google+ circle, you can say ‘All posts, posts tagged …’ and then you get a list of ALL the tags someone has used. When they add new tags, you would get notified (like you do when someone new follows you). “Bob has added a new tag called “Home Brew.”” Then you can decide to follow it or not.

    Of course this relies on Bob’s honesty, and sometimes he might forget to tag things. I do all the time on Tumblr, because they removed tagging from the forefront of my screen. WordPress’s habit of keeping them right there on the sidebar by default actually helps me remember that this is an important part of my social face. It’s not just who I am, or what I’m saying, but what I’m talking about.

    If you’re interested in some of me and not all of me, that should be easy to share too. After all, I may love my friends, but I really don’t care about Glee, and I’d like to be able to ignore all tweets labeled ‘#glee’ now and then.

  • TimThumb, Heroism and FUD

    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.

  • Share My Content (But Leave My Style Alone)

    Share My Content (But Leave My Style Alone)

    Four and Twenty 3.14159 in a PieThis came up at WordCamp Chicago. We were in the unConference, talking about BuddyPress, when John James Jacoby asked how many of us use Blackberry Pie. This is a WordPress plugin that lets you include Tweets into the content of your post, bringing the style (avatar, CSS etc) from Twitter. Then he asked if that would be cool to see in WordPress, where we could bring any other WP content to our sites.

    A lot of people liked that idea. I visibly cringed. Sam “Otto” Woods made a joke about how that would bring splogs to a new level. But I was stuck on thinking about copyright and bandwidth.

    The basic idea is sound and, I agree, really cool. If I can link to my site on Google+ or Facebook, and it pulls in a picture, couldn’t it pull in my formatting too? That would mean when you quote from my site, it looks like my site! The problem I see, is that the reason Facebook and Google can get away with embedding the picture is that they are copying your picture to their server and displaying it from their sites.

    Yep, these are servers.How do I know that? Because I have hotlink protection and I know it works. So the only way for these sites to cache my images is to come and scrape what they see IN the post. (I’m pretty sure this is why the ‘featured image’ in WordPress doesn’t always show up on a Facebook link. If you have the image inside the post, it always shows up. If you don’t, it doesn’t. Simplest answer: they’re content scraping.) It’s nice to see that technology being used for good. Of course, if you extend the thought, you’ll realize how many servers these sites must allocate just to storing snippets of other people’s data.

    If your server cannot do that, then you should not be trying to emulate them.

    People forget just how much work went into making Google and Facebook able to do that! They aren’t aware of how many servers, and how many people maintaining the servers, it takes to support that level of infrastructural deployment.(Mind you, WordPress has about 4 or 5 people to Facebook’s couple hundred, so it’s not about the amount, but the people.) This makes the problem two-fold. Either you must have your server set up to handle the caching, or you steal the CSS (and thus bandwidth) from someone else.

    Okay, okay, so CSS bandwidth is a drop in the bucket compared to images, I know. And maybe I’m making a mountain out of a molehill, but we already know exactly how dangerous it is to have your site heavily linked. I’ve suffered the Digg/Slashdot/ma.tt effect before, and been nailed with 300% traffic. Thankfully I built this server with that end-goal in mind, and the last time it happened, no one noticed. Which is as it should be. But if I was still on my old shared host, I’d probably have died.

    This cuts back to why certain things are made plugins/add-ons and others are default a part of a product. When you support ‘all’ things, you have to limit your product to what actually is supportable. Microsoft Office works on most systems, but it doesn’t work on all, and it has known conflicts. Because of those conflicts, there are features Microsoft knowingly left out! They would rather support as much as they can for as many people as they can. If your product is a niche product, you can get away with only supporting certain things, but a web app (Drupal, WordPress, etc) cannot. (And this is why you won’t see caching built into WordPress. Too many different server setups!)

    I just really like this mountainIn the end, I think that embedding contextual content in a site is a nice idea, but unfeasible. You’ll never be able to support all possibilities, and you’ll never be able to do it in a way that ensures you stay on the right side of the law. If you want to link to someone, make a quote, link back, and use it as a part of your site, branded your way. If the look and feel of the post is important (like Twitter or YouTube), then hope they’ve come up with a way where they want you to be able to embed the content in your site.

    Until then, share my content, but leave my style alone on my site, where it belongs.

  • Backup Where You Belong

    I’ll make it quick: At the end of the day, there’s only one person who’s responsible for your backups, and that’s you.

    Here’s the deal. WordPress does not have a 100% backup everything tool. Neither does Drupal nor Joomla.(All three of the big guys have plugins that can do this, don’t worry, I’ll get to that in a minute.) In fact, I don’t know of any app on the web that does. Even though Google says “You own your data!”, if you use their tool to download everything, it’s not in a form you can just slap back on the web. Their backups remain tied to themselves. You get the data, but then you have to parse it.

    This brings up a bigger question, though. What is the point of a backup? In a worst-case world, your backup is to save your bacon for when you screw something up. It’s to restore from a crisis or to roll back a bad change. So why aren’t these sorts of things built into applications?

    When you think about it, they’re not built into any application. From Microsoft Word to your favorite Twitter app, if an upgrade breaks something, there’s no ‘roll back’ option. You can uninstall and reinstall, but most of the time that means you have to reconfigure all your favorite settings.(This is actually why I try to make as few special config changes as possible.) Yes, in Microsoft Office, you can save your ‘document’ in total, but that isn’t a direct analog to Web Publishing, because there’s far more than ‘just’ your book, there’s all those settings and preferences. If you’ve ever tried to copy someone’s preferences and settings from one computer to another (and you’re not on a Mac, who makes that shockingly easy) you know what I mean.

    The best backup tools are things like Microsoft’s cloud backup, or Apple’s Time Machine. Both make a massive copy and then incremental updates to your entire computer. They are, as we say, OS (Operating System) backups. All your documents, all your applications, all your settings, are backed up. No individual application has ever bothered with this so why should a web app?

    The argument goes that you should be able to pick up your web app and put it down on another server via exporting. I can think of one app off the top of my head that can do that: Cpanel. I’ve never tried it myself, but I’ve been told it works pretty well. Still, Cpanel actually falls under the weird realm of operating systems, as it’s really a server management tool. It’s where you logically expect to see things like your backup tools, db access, etc etc and so on and so forth.

    In short, it’s the right place to see your backups made.

    How do you backup a webapp?

    Step 1) Backup ALL the files on your server.
    Step 2) Backup all your databases.

    That’s kind of it. For most well written apps (WordPress, Drupal, etc) to ‘restore’ these backups, you just copy them back up. For the database stuff, you may need to make a second database and edit your files to point to that DB instead of the original, but it’s pretty fast. Professionally, we have one-click rollbacks installed on databases, but even then, we tend to go ‘Oh, that didn’t work.’ and rename the NEW DB (databasename_date_BAD) and re-upload the old one. Why? Because it works. When the DBs are too big, we have incremental backups and rollbacks set up. Files ditto (actually for files, we ALWAYS have step one ‘make a copy of the old folder structure…’ and the rollback is just renaming things).

    We rarely rely on the applications themselves to perform these tasks for one simple reason: They’re BAD at it.

    I’ve always been an advocate of the right tool for the right job. A web app is good at its job. A backup tool is good at its job. The two may cross, but there’s nothing wrong with using a backup tool to make backups and a writing tool to write. I don’t use any plugins on my apps to make backups, I do it via the tools built into my server that are, expressly, for making backups. Ditto my computers at home. I know what the right tool is, and I use it.

  • Distributed Company

    Distributed Company

    In the past, a company’s staff all sat in the same area, cubes or desks in a little area where they were grouped by their job functions. Shipping sat here, processing here, accounting there. IT had the closet. As time passed and systems grew, teams became more diverse. The shipping mavens needed to know what the processing people were doing, and cross-training became the norm. People stopped being able to say they had one role at work, and started becoming generalists instead of specialists. There was always (and will always) be a role for the super specialist, but not everyone had to be one.

    In IT, this has become even more prevalent. It’s not good enough to just be great at Windows IIS, you have to know Apache, Lighttpd, nginx, and countless other systems, just to keep up with our fast paced world. Thankfully, a lot of us spend our time learning the basic concepts of how things work, we learn to think logically, and apply that skill to any product, regardless of our familiarity with it. We adapt.

    But for the brick and mortar companies, many people have sat ‘with their team’ for their careers, and the idea of splitting up is mind boggling. “How can we work if half the people I need to talk to are in another building?” they cry, after a reorganization moves people around.

    Here’s a true story.

    We split up our teams recently, into ‘Design The Software’, ‘Build The Software’ and ‘Support The Software.’ The designers are ‘architects’ who create the scheme of things and decide how the software will work. The builders do the grunt work and build it. The ‘Supporters’, for lack of a better term, are the folks who use it every day and answer the phone when it breaks. Oh yeah, they have to fix it when it breaks.

    Many of us straddle at least two teams, and some of us are in all three, so where you actually ended up has very little bearing on what you do, and more on where you sit. I sit a floor away from people I work with every day. Now, when a server goes down, someone over there may be working on it at the same time I am, and conflicts come up.

    We’ve tried to address this with ‘team twitter’ accounts (not actually Twitter, we made our own little applet for it in Sharepoint). Someone will post ‘Ticket Foo came in, I’m on it.’ and we know to look there first. Sometimes we post ‘Hey, server Bingo is crashing. Anyone know what’s up?’ and we’ll reply. Personally, I wanted to grab a page from WordPress and make a P2 blog where we could all just login and post, but that got shut down.(We’re trying to rewrite it for SharePoint right now, but oddly people are against sharing personal information with other people who already have access to that information…) Still, not everyone remembers to use it, and since it’s ‘just us’ and not a corporate initiative, we get people complaining ‘I have to run across the hall, down the stairs and down another hall to tell Bob about this!’ and ‘I can’t hear what’s going on!’

    We’re far too set in our ways, clearly. The fact that no one is willing to even try to look at the benefits of distributed collaboration depresses me. I don’t have to sit by someone to IM them a question. I don’t have to call them to ask a question. I have email, I have IM, I have a phone, I have a group ‘board’ where we can have lengthy discussions about ideas, before we sit down and waste an hour in a meeting.

    What I don’t have is buy in. I don’t have people willing to try something new. “The old way worked!” they shout. No, it really didn’t. It looked like it did, but how much time was wasted running around trying to find someone, not knowing where they sat, when you should have just put a message up and they should have read it, replied, and moved on. Interoffice memos in J.K. Rowling’s world were paper airplanes. Wouldn’t it be nice that you could use that? Oh wait, it’s called email!

    The future of communication in a company isn’t going to be ‘How do we schedule a meeting across four continents?’ but in ‘How do we keep our communication flowing, 24/7/365?’ At this point, my company has offices in over a dozen counties. We still rely on ‘shift hand-off’ emails which no one reads because we get too many emails to begin with. We have people who spend so much time filtering email that they half-ass updates to support tickets, so the next shift has only half an idea of what’s going on.

    Your company needs to be available when people use it. For a Bank (like I work for), that means every day except the days you’re legally obligated to be closed. Which means there actually isn’t a time when we’re 100% closed.(Sometimes I joke that the sun never sets on our company.) Obviously this isn’t true of all things. A grocery store should be open most hours of the day, if possible. A restaurant should have longer hours on the weekend. An on-line store maybe needs 24/7 support, or maybe it just needs 5 day a week so people can catch a break. But you decide when you need to be available, and then you make it happen. And if being available means you need someone to be around for 14 hours, then you need a way to hand off that person’s work to the next guy in a way they can easily pick up and run with.

    The future is decentralization. It’s time to embrace it and learn how to use it best.