A Bug With A Logo?

Heartbleed

We all know that we need to take our online security seriously, but we rarely do anything to improve our own situations. Even when we hear about data breaches, the odds that we’ll go and change passwords are relatively slim. We might get occasional emails and updates from the sites we log into about our security, but we tend not to get worked up for anything less than proof someone has been messing around with our personal bank accounts.

But Heartbleed has been different.

From the first moment I heard about Heartbleed, everyone I know has been taking it fairly seriously. Part of that is due to the nature of this particular security breach: the amount of data that was made accessible by a vulnerability in OpenSSL is enormous. It would be easier to list which major websites weren’t affected than which were. But while the details of the Heartbleed breach are enough to get programmers and website publishers worked up, they’re probably too technical to really intrigue the average person browsing the web. So why do so many people seem to know about Heartbleed?

A Well-Branded Security Breach

Fundamentally, Heartbleed is different from security breaches that have come before. It’s been branded and marketed, something that no one has really tried to do historically. The traditional approach to announcing you’ve found a security exploit was to write out a brief description of the problem and send it around to everyone you expect the problem affected. There wasn’t exactly an incentive to take action.

For the researchers who uncover security breaches, there isn’t necessarily a clear benefit to promote their work in other ways, however: the status quo was enough to get them credit for their work and collect any financial rewards (like rewards offered by companies to researchers who found security breaches in their systems before those problems could be exploited).

Heartbleed’s branding may prove to be a turning point in what we expect from a security breach announcement.

That branding wasn’t a particularly major effort from the organization that launched Heartbleed.com. That company, Codenomicon, didn’t discover the vulnerability, but does help other organizations secure their systems against malicious attacks.

Miia Vuontisjärvi, a security analyst at Codenomicon, told TechCrunch that the site started as an internal Q&A that Codenomicon’s experts wrote in an effort to get a handle on Heartbleed’s potential impact.

“Experiencing the pain of the bug first hand we got a nagging feeling that this calls for a ‘Bugs 2.0′ approach in getting the message out in an emergency. Ossi, one of our experts came up with Heartbleed as an internal codeame and from there on thing lead to the other. The domain was available and our artist Leena Snidate did a an excellent job in putting our pain into the logo. It all went much faster than expected.

“When the vulnerability became public we realized that this is going to be a crisis communication. We said what we had to say in the Q&A with as little litter as possible. We put it available on a low latency and high bandwidth content delivery network so that it is very accessible for anyone in the need. Based on initial reactions we did some minor edits but we quickly saw the Internet community picked the issue up in an astonishing way.”

Crisis Management in Open Source

One of the most noteworthy points about Codenomicon’s efforts is that OpenSSL is an open source project; Codenomicon had the opportunity to step in because the developers behind OpenSSL are all volunteers. When software is developed by a single company as a proprietary product, there are typically more concrete procedures to handle bugs and security breaches — usually developed in order to minimize liability for the company in question. I can’t imagine an established company being able to vet and publish information about a security breach in this fashion.

But while Codenomicon stepped up and helped make information about a particular security exploit easier to understand and share, there have been plenty of problems with open source code in the past where no one took on that sort of leadership role. That’s partly because taking a leadership role in the middle of a crisis is tough; contributing to open source code bases doesn’t automatically enable you to field questions from the press, manage a user notification process, or brand an exploit so that users will upgrade their systems.

The open source community, as a whole, could benefit from establishing some best practices on how to handle this sort of flaw. At a minimum, just creating a check list that researchers can follow to make announcements more useful to the average internet user could be beneficial. While that’s not my area of expertise, there were both good and bad factors in the announcement of Heartbleed that could be used as a starting point for such a response framework:

  • Advance warning: Some large companies got advance warning of Heartbleed, which allowed them to patch their system before the exploit was announced more widely. While I have no problem with offering advance warning to companies likely to be hit hard by these sorts of breaches, there’s definitely room for a more systematic approach to deciding who to contact and how to handle the question of advance warning after the fact (if only so that complaining about not getting advance warning doesn’t become more of a story than the original exploit).
  • Embedded devices: As more devices are are plugged into the internet, security announcements need to at least mention what sort of systems will be affected by a given breach. It isn’t always possible to guess how a given piece of open source software may be used, but such warnings need to be offered to the greatest extent possible.
  • Points of contact: When we’re dealing with a breach in open source, where everyone involved is a volunteer, choosing who will serve as a point of contact is tough. These sorts of situations can require numerous hours to resolve, let alone to handle email. But someone has to do it, even if it’s someone outside the core development team.

Some of these points could be made easier with the application of a little money. With Heartbleed as motivation, several companies are looking at the value of investing some money into the open source infrastructure that drives their business ventures. Google, Facebook, Microsoft, and many other companies are on board to support a new group called The Core Infrastructure Initiative. Hopefully, this initiative will be enough to help major open source projects handle both security and breaches more effectively in the future.

Crying ‘Security Breach’ Too Often?

Heartbleed’s branding may be new, but researchers are starting to embrace the idea. In a post on a new vulnerability, researcher Matthew Green noted:

“First, if Heartbleed taught us one thing, it’s that when it comes to TLS vulnerabilities, branding is key. Henceforth, and with apologies to Bhargavan, Delignat-Lavaud, Pironti, Langley and Ray (who actually discovered the attack), for the rest of this post I will be referring to the vulnerability simply as “3Shake”. I’ve also taken the liberty of commissioning a logo. I hope you like it.”

But we need to consider if embracing this level of branding is a good idea for all security breaches. Embracing this sort of promotion can make it harder to get people to take action in the future: just like a child crying ‘wolf’ may not get attention when it matters, an important security breach can be lost in the mix. Reserving this level of branding for the truly crucial lapses in security is necessary to ensure it still works.

Security expert Bruce Schneier put it bluntly in an interview with the Harvard Business Review: “There’s a risk that we’re going to be accused of “crying wolf.” If there isn’t blood on the streets or planes colliding in midair, people are going to wonder what all the fuss was about — like Y2K. If you slap logos on every vulnerability, people will ignore them and distrust your motives. But it’s like storms. The bad ones get names for a reason.”

It’s also worth noting that Codenomicon helps its clients handle security issues. Making those security issues easier to understand and respond to is a brilliant piece of marketing work (along with a good deed that benefits internet users as a whole). But this sort of marketing effort is easy to exploit by companies that choose to do so. Whipping up a frenzy over relatively minor security breaches might make sense for some companies’ bottom lines. That’s absolutely not the case with Heartbleed and I’m not trying to make Codenomicon’s motives sound suspect, but it is a factor to consider as we see more security vulnerabilities branded for easy consumption.

Photo Credit: Leena Snidate

Should You Touch The Code On Your Blog?

Looking under the hood on a website can be intimidating, especially if your creative talents don’t lie in that particular direction. Just the same, I consider tinkering with the code for my website to be one of the best decisions I’ve made for my business.

To be clear, I don’t mean building my own website with one of those ‘automatic website builders’ that certain web hosts offer. I mean that I know a little about what makes my content management system (currently WordPress) tick, as well as a bit about HTML and CSS — the parts that drive the design of the site. As a business owner, it’s tempting to try to do everything myself, but that’s not actually a good decision. I know better than to rely on my own coding skills when it comes to putting together a site. Rather, my main goal is to know enough to be an active part of the process.

I like to compare my level of coding knowledge to my level of plumbing knowledge: I can’t fix a major leak, but I can at least deal with a dripping faucet. I have enough general knowledge that I can handle minor fixes on my own, especially if I can Google for a tip or a tutorial. Perhaps more importantly, I know enough that neither plumbing nor web design jargon sounds like a different language to me. It’s a lot harder for someone to sell me something I don’t need or take advantage of me. If only for that reason, I definitely encourage improving your technical literacy whenever possible — even if you don’t need to use it directly.

Do We Need an Algorithm Beat?

The idea of the beat reporter is alive and well, even if the institutions that sparked it aren’t doing so well. Bloggers — especially those who come from a more traditional journalism background — tend to focus very closely on specific topics if they want to do well. They are beat reporters, of a sort, just as many publications train reporters to be experts in a particular niche.

But the beats that may be crucial in today’s world aren’t quite the same ones that most general interest publications rely on. Sure, I still need to read what the health, real estate, and crime beat reporters produce.

The idea, however, that technology is entirely separate from everything else and can be covered by just one beat reporter is severely outdated. First of all, divorcing the relevant technology from topics like business and health removes it from the context that readers need to understand the topics. Technology is integrated into every part of our lives; even someone who doesn’t use technology personally brushes up against it every time she leaves her house.

Second, however, there are certain issues related to technology that, when bundled together, make an overwhelming mess for a reporter. Having the same person covering privacy issues and reviewing the latest hardware specs just doesn’t make sense. Nick Diakopoulos makes a very good argument for creating beat reporter positions that cover algorithms specifically. Personally, I’d love to see a privacy beat.

How these changing beats may play out is more a question of resources at individual publications than pure journalistic idealism but hopefully editors will take note of Diakopoulos’ article and consider who should really be covering what in their newsrooms.

Are Tools Like Zapier the Same as Programming?

7413565310_f75199807d_o

Truly amazing things can happen when you can pair one app with another, integrating the results to get something better.

But the actual integration process slows down the speed at which such mashups can be rolled out — or at least it did. While there are still plenty of apps that require developers to write custom integrations for each set of apps they want to pair together, web-app automation services like IFTTT and Zapier make it possible to come up with new integrations on the fly, without writing a line of new code.

Personally, I find these services to be the greatest thing since sliced bread. While I know the basics of writing code, I’m still at the point where I have to write out exactly what I want to happen in fairly specific detail. That usually happens to be in the format that if this one thing happens, I want this other thing over there to happen next. As it happens, IFTTT stands for ‘If This Then That’ — the short form to the average approach to deciding what simple computer programs will do.

Are IFTTT, Zapier and Tools Like Them Enabling a New Type of Programmer?

As I started outlining this post, I had an incredibly difficult time figuring out just what these tools are called: “web-app automation service” seems to get the most use across various technology blogs, but it’s a mouthful. We just don’t seem to have the right words to clearly describe what’s going on when you log into one of these sites.

Part of the problem is that while the various web-app automation services seem to be doing something novel, the reality is that what’s on offer is more a matter of user interfaces than anything else. Every single app that IFTTT and Zapier offer connections for has some sort of API — an interface that a developer can use to make use of the app in her own programs. That API might be available for free or it might have a price tag attached, but it has to be already present for a web-app automation service to tap into it.

Furthermore, if you look at the actions you can take with a given app through a tool like IFTTT and you’re also willing to dig through that same app’s API documentation, you’ll find that the actions you can take using that app are basically identical whether you’ve got an automation tool acting as an interface or if you’re willing to write some code.

If you’re getting the same results a programmer would, using the same tools (albeit with a little something special added on), are you a programmer automatically?

The question of Zapier’s place in technology today is particularly interesting because Zapier has been on a big push to add new apps to the many it already integrates. The company added a new app every day in February. Last month, Zapier announced an improved developer platform, making it easier for developers to connect their apps up to the platform. (I may have taken the announcement as a cue to nag a few developers I know about why they should invest some time in improving their integrations.)

Good Programmers Use Time-Saving Tools, Right?

It’s tempting to dismiss web-app automation services as not meeting the ill-defined standards of exactly what counts as programming. But we shouldn’t be too quick to judge.

Programmers are well-known for a willingness to embrace all sorts of tools to make their work easier. Consider frameworks that sit on top of programming languages to speed up development dramatically. Ruby on Rails, for instance, has become a favorite of new programmers because it hides a lot of the more complicated aspects of programming under some friendlier tools. As a result, new programmers can build websites and apps much faster with Ruby on Rails than if they were to use Ruby on its own.

While I have heard some grumbling from old school programmers that anyone who uses a development framework isn’t a ‘real’ coder, I’m pretty sure that the same people find plenty of other ways to exclude as many people as possible from the little club they’ve built for themselves. I’m okay with being picky about the development frameworks you personally want to work with, but there’s no doubt in my mind that using such a framework is definitely programming.

Tools like Zapier and IFTTT aren’t much different than frameworks: the user still has to invest plenty of time into figuring out what they want as an end result (unless they’re willing to stick to premade recipes). Even those premade recipes, however, can feel a bit like templates that you should tweak to your own uses, just like every programming tutorial. Sure, using a web-app automation service isn’t a particularly robust approach to programming, but it requires enough of the same mindset that we should take it seriously.

The Real Gateway to Programming

I have plenty of friends and acquaintances who are working on the question of how to get kids interested in programming. One of the favorite approaches seems to involve getting kids playing games that incorporate aspects of programming. But while getting kids to play video games may be a logical strategy, taking a more basic approach may have more value.

Just because an individual happens to be young doesn’t mean that she doesn’t have problems in her life that she wants to solve: I can’t even count the number of times I get calls from younger friends and family members asking how to do something technical (I might be considered technically savvy in some circles). And, sometimes, I have to tell them that there isn’t currently a tool to accomplish exactly the results they’re after. Suggesting that they learn to program and build their own solution rarely goes over well.

But what if there was a web-app automation service that focused on the tools that younger users rely on? How hard would it be to convince kids to sign up for the service? Finding the apps to include certainly wouldn’t be a problem: Snapchat is pretty popular, but the various educational apps that teachers now use to assign and manage homework. Most of these apps already have APIs in place, even if those APIs aren’t widely advertised. With the right connections in place, I’m certain that it would be easy enough to get younger users to use such a service.

Having to start thinking in that if-this-then-that format provides a certain entryway into a programming mindset — one that would making teaching the process of writing code much easier. Even better, once kids start using such a service, they’re almost certainly going to come up with more ideas for combining pieces of technology, some of which will require more advanced programming skills. Making the leap just isn’t that hard at that point, especially in comparison to the change between thinking that you’re doing something just for fun and suddenly needing to shift to be able to think of that same process as work.

These Tricks Aren’t Just for Kids

Clearly I’m a big fan of web-app automation services (even if that name makes me cringe every time I type it). At the very least, I see them as a way to minimize copying and pasting information from one computer window to another. But I also see them as an amazing opportunity for how businesses can move forward.

We don’t have to have big behemoth software packages that all come from the same company in order to guarantee our tools work together seamlessly. We have more options (or at least will when tools like Zapier are a normal part of our day-to-day processes). We have the freedom to use the best application for a particular task, no matter who makes it, as long as the developer in question has built an API — and that’s fairly standard practice, even when an application doesn’t advertise its API as a feature. Just go through the web-based apps you already use and check for the word API. It’s usually down in the footer of the front page.

But these tools also do good things for how we think about business problems. We’re moving into an age where every business generates absurdly large amounts of data. Just being able to move that data around efficiently makes a web-app automation service valuable. But getting us in the mindset of thinking about how we can use that data in different contexts — if I take in this piece of information here, how can I push it out over there? — improves our ability to run our businesses.

Not everyone needs to know how to write code to run a successful business, but I would argue that every entrepreneur does need to understand at least the basics of programming. In particular, knowing what’s possible is crucial, whether tools already exist with a given capability or if you’ll have to go out and find someone to put together the code. If you don’t have the right mindset, you’ll slip behind the competition as they find and build new tools. But if you can just write simple statements of what should happen after a certain triggering action, you have the skills to team up with an experienced programmer to create the application that will revolutionize your industry. Beyond that, you don’t need much more than a good idea.

Image by Flickr user Thomas Amberg

Our Tools Dictate the Way We Think

The tools we use for writing change what we have to say. While most of the time I write in front of a computer, I also spend a lot of time writing long hand.

I use a fountain pen and a legal pad — an echo, perhaps, of reading about an author who did just that when I was still in high school. I’ve had an obsession with fountain pens for longer than that. I remember my dad letting me use his pen when I was you — a massive pen that I could barely write with, let alone write in cursive.

But, obsessions aside, I’ve noticed some major differences between the words I write with a pen and those I write on a computer. The self-editing process is one of the most obvious changes: on a computer, it’s practical to keep going back to the previous line and making changes. I shape my sentences, add transitions, and even eliminate repeated words all through the process of writing.

Making changes when writing by hand is far more difficult, so I tend to just write. I tell myself that when I type up a particular project I can edit it then. It’s more of an ideal way to write — it’s easier to get into the flow of the process and press on.

I like to say that I don’t get writer’s block. Wanting to eat keeps me motivated and moving forward. The reality is, of course, more complicated: I can’t afford writer’s block, so I build approaches into my day that keep my brain rolling. I write on my legal pads first, getting myself in the flow of writing. I essentially prime the pump so there are already words coming out before I start working on the computer. I rarely handwrite anything for a client, but getting to work on something I enjoy first seems to help even more, so I don’t worry about my topic first thing.

Part of the reason I keep client work to the computer is that I’ve noticed some key differences between my style on paper and on screen. I’m more willing to describe my own experiences away from the screen — a part of me feels that paper is less judgmental. But even my sentence structure varies: when I write on a computer, my sad addiction to parentheticals and appositives becomes evident. On paper, I use them much less often. I prefer simple sentence structures, perhaps because they are easier to construct when you don’t have the option of self-editing. I do have a tendency towards colons when writing by hand.

Word choice is another place where my writing diverges, though perhaps not for the reasons you think. When I work on my computer, I have a piece of software called TextExpander turned on. There are certain words and phrases that I don’t want to appear in my writing, mostly because I overuse them. When I type those words, TextExpander ‘expands’ them into glaring reminders to avoid using those verboten word choices. Of course, there is no way to automatically delete words when writing by hand. I do sometimes notice that I’m spelling out a word that Text Expander will take me to task on. I’ve got an anti-authority streak a mile wide, so I generally take pleasure in writing those words all the way out

Science has demonstrated that we think differently with a pen in our hands than with our fingers on a keyboard. That’s why students with learning disabilities, like dyslexia, are often handed a laptop. One is not better than the other — they’re just different options. And for anyone doing creative work, having those options is useful. When you re trying to create and there’s a problem, having a way to entirely switch the way you think about your work — perhaps just by taking a few steps — is invaluable.

I see a tendency in many fields to teach only computer-based skills — usually because working through a computer is so much faster. But the underlying skills are valuable. Even in computer programming, being able to step back and write out some pseudo-code can be a useful skill. Sink some time into doing your work the old hard way. You may be surprised by the results.

Keeping the Open Source / Creative Commons Eco-System Healthy

9645435189_32282abc3b

When writing blog posts, particularly for clients without a budget for images, I rely heavily on the kindness of strangers — those strangers who post their photographs to Flickr under one Creative Commons license or another. I’ve been known to get downright snooty about how carefully I search out the images I can legal use; it irritates me to no end when someone tries to tell me that they can just use any image they find online. But while I have my nose in the air, I also feel a bit hypocritical: I’m not contributing images back to the Creative Commons pool that other people can use for their own projects.

Photography isn’t my passion; I mess around with Instagram and other photo apps, but I don’t do much else. I don’t have a lot of photos I feel are worth releasing to the world.

I don’t think I’m taking advantage of all those photographers who feel comfortable sharing their work despite my pangs of guilt. I’m religious about providing links back to the work of the photographer (or other creative) who provided the work I’m relying on. When requested, I’ve even gone back and edited old posts to make sure that I’m linking to a creative’s preferred online presence or using the anchor text the photographer prefers.

Appropriate attribution is the least I can do, though. Good stock photography is expensive and photographers licensing their work under Creative Commons are (at least theoretically) foregoing some income. Links are something of a currency, at least online, but they may not be enough to keep the Creative Commons ecosystem healthy. What I should do, at least in my own mind, is to release some amount of my own writing under a Creative Commons license, to be freely used.

So why don’t I release my own work under a Creative Commons license?

Part of it is a question of mechanics: I earn my living from my writing, at least the first time a given article or ebook appears anywhere. Licensing work in such a way that I can get paid requires hanging on to copyright, at least in the short-term. I’m not saying that those photographers posting their work under Creative Commons licenses shouldn’t be able to earn a living. However, more than a few of those photographers have other sources of income.

But part of the problem is that there’s no clear incentive for me to release copyright: if I write well, I’m going to get those inbound links (the currency of of the web). It’s relatively rare that anyone wants to republish an article that’s already freely available on the web on some other website. The search engines don’t reward such behavior, after all. I do occasionally get requests to reprint my work offline, in actual print. I routinely allow non-profits to reprint my work without charging them a fee. I’m even open to allowing someone who stands to turn a bit of a profit use my work without recompense. But there are plenty of companies that I’d rather not license my work to without compensation (such as textbook publishers, who have occasionally approached me in the past).

The Existing Incentives for Open Source

The Creative Commons and open source communities have a huge amount of overlap. But open source is more effective: more people using open source software seem to make a habit of putting work back into the eco-system. The open source approach to software is very well established: if you’re currently reading this, you’ve touched multiple pieces of open source software even if you didn’t realize it. Many content management systems, servers and other online technologies run entirely on open source software.

WordPress, for instance, is made available under the GNU General Public License, an open source license. Anyone who wants to download WordPress’s files and use them to set up a website can. There’s a clear benefit to that kind of availability: WordPress has been downloaded over six million times, which doesn’t even take into account the number of WordPress.com accounts there are or the number of developers who have set up multiple WordPress websites from a single download. There is no way for a software product to grow that dramatically in a closed system — and that kind of growth can be a major incentive for someone to contribute to open source software. While WordPress’s contributors haven’t exactly become household names, they do enjoy a certain amount of celebrity among people in the know.

There isn’t a lot of money that goes with that relative fame. There are a few particularly profitable WordPress-based businesses, as well as other companies based on building open source software. The licenses, however, aren’t built with developing strong business models in mind, purposefully. There are some options, like Creative Commons’ Non-Commercial license which allows for free use of creative work, provided that it isn’t for a commercial process, while still allowing the creator to financially benefit from her work, but these licenses aren’t always the easiest to earn a living from. That’s not necessarily a problem, provided that the creatives making their work available under some sort of open source license feel adequately rewarded.

Some people just want an excuse to work on cool projects and to make sure that other people have access to those cool projects. But altruism and fun aren’t the strongest of incentives. If something else comes up, it’s easy enough for an open source contributor to walk away from a beloved project: maybe someone else will take over maintaining it, maybe not. It’s a question of whether someone else has as much passion for a given project as that project’s founder.

There are certain side benefits that have evolved that lead people to contribute to open source for less noble reasons. For software developers, writing code under open source licenses can be one way to build up a visible portfolio. That in turn can make finding paying employment much easier: recruiters routinely go through popular open source projects to find prospects, as well as browse through profiles on GitHub.

Are Those Incentives Enough?

Even with the incentives present in building open source software and releasing other work under extremely permissive licenses, there are plenty of projects that just wither away. The underlying files may be available online somewhere but they aren’t updated to work with newer software versions or kept current otherwise. These are often projects that individuals and organizations depend on and have a vested interest in improving.

In my mind, these situations are proof that there’s room for further incentives for open source communities. I’ve seen more than one situation where a company wound up hiring a developer just to bring an open source project back up to the point where the software was usable again — and then choose not to release that code for some reason or another. There needs to be a cultural incentive for companies (as well as writers like myself and other creatives out in the world) to pass material back into the open source and Creative Commons ecosystems.

At a minimum, that means creating mechanisms for streamlining that process and educating users about ways to support open source. Returning to the WordPress community for a moment, it’s worth noting that many users who set up blogs on WordPress.com or even on their own sites don’t understand what open source software is. They just know that they can use WordPress for free. Even a little education goes a long way with such users.

Where does all this leave the open source ecosystem?

Perhaps it’s not in the easiest place in the world, but the situation is actually pretty good. We’re incredibly lucky at this point that enough people are willing to give their time to creating amazing projects that the rest of us get to use and enjoy. The ecosystem is healthy enough, at this point, to keep going for the foreseeable future.

But just because things are humming along now doesn’t mean that there isn’t opportunity for improvement. It’s a good time to discuss how we want to grow open source communities in the future and what we want the norms of these communities to be. We are starting to reach a point where some of the original proponents of open source may be thinking about retirement (Richard Stallman, the author of the GPL, turned 60 this year, for instance). That means that those of us who are newer to the worlds of open source and Creative Commons are going to need to step up.

So, what do you want the licensing of your creative works to look like in the future? How do you want to benefit from them and what are you willing to give back to the community?

Image by Flickr user Dennis Skley

How Much Infrastructure Do You Need to Build to Get Where You’re Going?

2862306654_2a2b542444

You can work without infrastructure. Some people compare it to an acrobat working without a net, but it’s more like an acrobat working without the rings, high wires and other apparati that makes an act more interesting. An acrobat can still do plenty of flips and other tricks without the tools of her trade, but avoiding audience yawns is significantly harder.

The same goes with practically any business. I’m always surprised by what people can do with their bare hands and an awful lot of time. But the moment you give someone the right tools, everything’s easier, quality’s higher and she may even wind up with some spare time. Infrastructure, whether it’s the customer relationship software that makes it easier for you to sell your products or the note-taking app that manages all the little details of your life, improves your ability to get good work done.

It’s hard to argue against infrastructure. But actually getting the right infrastructure isn’t always as simple as making a trip to the corner store.

Custom Infrastructure Versus Off-The-Shelf

One of my problems with finding the right infrastructure is that I can never find exactly what I want — a content management system doesn’t quite match the vision I have or a survey tool doesn’t have enough flexibility in the types of answers it accepts. I get caught up in tweaking a tool (or even building an entirely new tool) so that I can have exactly what I believe I need. I’m not exactly the best at working within the constraints of a system.

It’s a bit of a trap, though: building your own infrastructure can take a lot of the time that you might otherwise invest in actually going out and getting started on what you want to accomplish. Sure, you may be able to turn around and sell that infrastructure to someone else, provided it isn’t too customized or it isn’t the secret sauce that sets you apart from the competition. That route has built plenty of fortunes — think about the oil booms. The people who are guaranteed to turn a major profit when everyone is out looking for oil are the guys selling the drilling equipment. Infrastructure is almost always a good bet.

But it can also slow you down if you’ve got a great idea that you need to get to market. You can distract yourself with perfecting the infrastructure when you should really be pushing full speed ahead, even if you have put together a patchwork approach to managing the whole thing until you get it to market. On the other hand, there are projects that you may pursue that the infrastructure just doesn’t exist for yet. If you can’t buy an off-the-shelf solution and cobbling together existing components won’t get you where you need to be, you have to find a way to balance that problem against actually accomplishing what you’ve set out to do.

How Much Infrastructure Do You Really Need?

It can be tempting to keep looking for the best tools. You can get bogged down in the details and never actually getting around to building the business you’ve planned all this infrastructure for. It’s a dangerous pit to fall into, another temptation that can drag you down.

I get bored with my infrastructure, which may seem like an odd thing to say. But I am excessively fond of playing with new tools: some people collect stamps, while I collect web apps. If I let myself, I could spend all day every day trying out new combinations of tools, without making any progress on the projects that I actually consider important. I’m not the only one, either, at least among the types of people who haunt productivity blogs. The only option in a situation like this is to draw a line in the sand for yourself. You can tweak and test and tinker to a certain point, but no further.

It doesn’t seem like a bad thing in the moment, though. I cannot begin to describe how much fun I get from tinkering with my workflow or building a custom tool. It’s a fast way to lose hours that I meant to spend elsewhere, but it’s easy to justify with the idea that if I can just find the perfect workflow, all of my work will do itself and I can kick back.

But I’ve had to find a stopping point in that eternal search for the perfect approach to work and — if you want to actually get any of your work done, you’ll need to as well. Make it clear to yourself under what circumstances you’ll return to the search: since I tend to write about workflows and related topics fairly regularly, I’ve divided the question into when can I try out a new gadget or app and when can I make major changes to how I work. Respectively, those times are when I can line up a place to publish a review in advance and no more than once a year.

Revisit Your Infrastructure Reasonably Regularly

Google recently announced that Google Reader will be shuttered later this year. As it happens, Google Reader has been a major component of my workflow for years. I have obsessively created an organizational system of all sorts of RSS feeds. I have layers of plugins that automatically act on the items I star and tag. I even have a carefully considered guiding document on what is worthy to make it into the one folder I read religiously every day. The end of Google Reader is going to leave a major hole in my infrastructure.

That’s given me a reason to start going through the many other RSS readers currently on the market. I’m pretty upset about the end of Google Reader, but I’m having some fun trying out all the different alternatives that have evolved since I last really investigated RSS readers. I’d considered the matter a solved problem and haven’t revisited it in years because I knew it was something of a rabbit’s hole I could fall down.

I try to keep from tinkering unless there’s a particular problem with my existing set up. Optimizing the tools I use isn’t enough of a problem to spark an investigation into what other options are out there (unless it’s been a really rough week and I need some cheering up). It seems like waiting until something goes wrong could be dangerous — after all, you could wind up using less advanced tools than the competition. But considering how often web apps disappear or an upgrade removes a feature that I rely on, I’m pretty comfortable with the speed at which I try out new options.

Infrastructure is a Learning Experience

I do make a point of learning about new options long before I try them out, though. I want to have a more limited field of possibilities before I dive into trying out a bunch of things.

But it’s worth going even further when learning about infrastructure at an even deeper level. After all, if you know what makes your tools tick, you may be able to tweak them yourself. There are different layers to this sort of learning: just going a bit deeper than the typical user’s experience in a given piece of software can be great — just being able to install a plugin on top of a given piece of software will put you ahead of the game.

I’m becoming a bigger proponent of learning how to hack on existing software, even if you’re not prepared to devote yourself to learning all about a given programming language. Just knowing a little bit about what is possible and what isn’t can make it easier to find someone already doing all the hard parts — or to gear up to building your own infrastructure yourself. I won’t declare that everyone under the sun needs to learn how to code, design, write or otherwise create, but the more of these skills you have, the more infrastructure you can build or adapt to your own needs.

After all, isn’t having the best possible set of tools the ideal? That we have the right infrastructure to speed up everything that we want to do?

Image by Flickr user Pinguino K

TextExpander: A Useful Tool for Writers

te_ss1

There’s a benefit to finding a niche, especially as a writer: you can make sure that you know the topics you work with inside and out. You know exactly where to look when you need a particular piece of data for a project. You can be an expert, to the point where people beyond your mother look for the work you’ve put out.

But you’ll also wind up typing the same things over and over and over again.

It’s a small price to pay: you can be truly adept with your vocabulary, provided you’re prepared to get as familiar with it as that one pair of pants that you can’t wear out in public, but that you will never throw away.

Taking Advantage of Over-Familiarity

But if you’re going to get that personal with your jargon, why not take advantage of the fact? Why not use that reality to speed up the time it takes you to do your work?

What if you could type a shortcut on your keyboard that would put those terms on the page with three keystrokes instead of ten? Over the next couple of years, that could add up to some real time. I do exactly that with TextExpander, a shortcut management tool available for the Mac.

Since I write about business quite a bit, typing ‘ap;’ spits out ‘accounts payable’ into my documents. That doesn’t seem like a big difference, but after you get used to typing something a little different, it can make more repetitive work go a lot faster.

I’ve got shortcut for all sorts of things:

  • the names and websites of the clients I work with regularly
  • templates for certain projects I work on (for instance, I have a weekly column that has to follow a very specific format)
  • the bio that I drop in at the end of articles I’m writing for certain publications

But there are some very cool ways to take shortcuts a step further, particularly if you spend most of your day putting words in a row.

Using Shortcuts to Improve Your Writing

If you write constantly, you’ll start to notice that there are certain phrases or even individual words that you use too much. Most of us are aware of such problem phrases, but it’s tough to write and find those phrases at the same time. You might pull a couple out during the editing process, but then again, you might miss them.

Every time I type certain phrases that I’ve decided I need to eliminate from my writing, TextExpander drops in an expansion that I can’t help but notice when I edit and that usually will catch my attention as I’m writing in the first go around. It usually looks something like ‘////////////BAD PHRASE/////////////’ — which is pretty hard to miss. I haven’t been able to entirely train myself out of using such phrases, but I’ve been able to improve the end product quite a bit.

There are also some words that I can’t write correctly for the life of me. I have certain suspicions about the way ‘soldier’ really ought to be spelled: I’m pretty sure there is a conspiracy around any word where vowels hang out next to each other. Rather than spend a lot of time stressing about conspiracy theories, though, I’ve created shortcuts to automatically correct my most egregious errors.

There are plenty of other ways to take advantage of shortcuts as a writer. I know I’m still only scratching the surface of how I can make my own workflow more productive, but I’m certainly going to keep experimenting with TextExpander and other tools.

A Little Bit of Markdown Makes a World of Difference

Over the past few months, I’ve made the switch to writing just about everything in Markdown. It’s a bit like writing in HTML — but much easier! I’ve reached a point that it would be hard for anyone to convince me to go back to my previous approach. I’m becoming a bit of an evangelist to convince other writers to start using Markdown, along with a few associated tools, to make workflow management much easier.

My Previous Approach

Prior to switching to Markdown, I wrote out blog posts (along with most other text) in a bastardized version of HTML. The goal was to be able to copy and paste what I wrote as plain text, without having to go through and change styling on specific words after I loaded a post into WordPress, or wherever else it was going.

You’ve probably seen horribly wrong results from cutting and pasting styled text from something like Microsoft Word into WordPress — if you haven’t, I strongly suggest against relying on this approach if you routinely write for the web. But, at the same time, writing in a text field on a browser just seems like begging to lose hours worth of work. Many sites now have some level of auto-saving built in, but it’s not something you can count on.

All of this added up to my adding in certain HTML tags directly as I wrote. But doing that can be a little distracting. Trying to figure out what a headline should say, as well as remembering which tag will result in the style you want can be a hassle.

Markdown to the Rescue

HTML is what’s known as a ‘markup’ language. So is Markdown, albeit greatly simplified. It’s easy to remember — asterisks do a lot of heavy lifting, as do octothorpes (also known as pound signs). It’s almost like adding a few little symbols to remind yourself to go back and add formatting latter. Luckily, though, with the right tools, the formatting winds up adding itself.

For me, those tools include the following:

  • Marked: This little app makes everything else possible. I write in Markdown in a variety of different programs, but I always have Marked running. It lets me generate live previews of what my text actually looks like from different types of files, as well as copying my work as HTML, so that I can drop it into a blog editor — or exporting the file as HTML, RTF or PDF.
  • Sublime Text: If you’re writing in Markdown, you’re going to want to write in some sort of text editor. I’ve been learning to code, so I just use the same text editor for everything. As an added bonus, there are some plugins for Sublime Text that make it into a great word processor. However, I only use Sublime Text for shorter peices of work — for longer pieces, it can get unwieldy.
  • Scrivener: For longer projects, I’ve started using Scrivener — not only is it Markdown friendly, but it has a ton of features for making big writing projects very easy to deal with.

That’s about $120 worth of software that makes my writing life much easier than it has been in the past. But you don’t need any of it to get started. You can rely on just about any text editor you may already have and try out some free tools for whatever platforms you’re working on; many content management systems have plugins that let them handle Markdown natively. Give it a whirl. I promise, you’ll be surprised.

WordPress, the GPL and a Business Nightmare

I use WordPress on every site I own. I ask clients to use WordPress on their sites (and I tend to avoid even high-paying clients who don’t). I even speak at WordCamps — I’m the one yelling about content strategy to a room full of non-writers every few months.

But last week, I found myself looking at other content management systems, wondering how hard it will be to switch away from WordPress. That’s ‘will,’ not ‘would’ because I’ve committed myself to slowly migrating away from the platform unless something major changes. The issue isn’t so drastic that I’ll migrate every single site I own in the next month — the process may very well take years at the speed at which I move.

The Problem with GPL

WordPress was my introduction to open source on a practical level. I’d encountered Linux and some other open source software in high school and college, but I never used any open source software on a long-term basis or to the point that I needed to figure out what I could legally do with it before WordPress.

As it happens, what we can do with WordPress is a little more complicated than it might otherwise be. That’s due to the Gnu General Public License (more commonly known as the GPL). If you aren’t familiar with the GPL, consider it to be the equivalent of any agreement you have to click through to use a piece of software. The main difference is that, like all open source licenses, the GPL lays out the ability to pass a piece of software along, change it and otherwise interact with it without violating the creator’s copyright. Where the GPL differs from some other open source licenses is that it is categorized as a Copyleft license. I’m not going to go into depth on the differences between types of licenses, but I will include a short working definition.

When a developer modifies a piece of software that was originally licensed under the GPL and distributes it, the result (known as a derivative work) must also be released under the GPL. The same is true of ‘linking’ to GPL code, which is generally interpreted to include writing plugins for an existing piece of software. Stick a pin in that last part — we’ll be coming back to it.

WordPress is released under the GPL. The way that the WordPress Foundation interprets the GPL, plugins and themes for WordPress all automatically inherit the GPL, including pieces that aren’t actually code. For instance, if a specific photo is used as a background in a theme, it has to be released under the GPL with the rest of the theme.

You’ll notice that I keep using the word ‘interpret.’ That’s because there’s no case law for the GPL — it’s never been fully legally tested. Almost every case that has gone to court in the U.S. has been settled (the main exception is one of a series of lawsuits filed on behalf of BusyBox). Richard Stallman wrote the original version and let it loose on the world. Later iterations have been created with advice from legal experts. At the most basic level, though, the GPL is a cool idea dreamed up by a computer nerd. It will take a series of judges’ ruling to set how the license is interpreted in stone. In the meanwhile, some developers define ‘linking’ as including an API call while others limit it to using other code in such a way that it’s included in the code of the new program. There are similar differences in just how to define a ‘derivative work.’

This alone is problematic for anyone running a business based on WordPress, or any other software licensed under the GPL. In theory, any day now, a case could go to court about how to interpret the GPL and completely change everything. It’s difficult to predict end results of such a ruling: I could see a situation in which I might suddenly need to make software that I’ve customized for my business available to the entire world. Software that I use that might be improperly licensed could disappear or stop working overnight. I could even imagine a situation in which software under the GPL needed to be re-licensed under a new license. It’s not the end of the world, but no small business owner wants to suddenly be informed that she needs to change something about the platform she runs her business on.

Furthermore, the GPL spreads in a particularly viral manner. It is written so that it drags new software into an open source license kicking and screaming. Just about anything related to a project licensed under the GPL winds up with the same license, because you can’t connect a piece of software licensed under the GPL to one that isn’t. It’s not the worst open source license, in terms of turning everything it touches into open source, but it’s up there.

A lot of developers (both individuals and companies) try to get around the problem by choosing not to release their work. Google, for instance, relies on a ton of open source code that the company’s engineers have tweaked. But because the code itself is not distributed — you only get the search results from Google Search, not an actual piece of software — Google isn’t required to release its source code.

But for companies smaller than Google, things aren’t so simple. Consider a freelance developer who makes his living customizing themes for WordPress for his clients. The typical interpretation is that when that customized theme is swapped for money, it’s been publicly distributed — even though the freelancer only made one copy, for an individual client.

We’re getting too far down the rabbit hole of open source licenses here, but I want to impress on you that this is not just complicated: it’s completely open to interpretation. The standard practice is to follow the interpretation of whatever individual or organization manages a given open source project, which is where the problem with WordPress lies.

The WordPress Foundation’s Interpretation

The WordPress Foundation has gotten into some fairly public arguments with theme and plugin developers over how to appropriately license their work. The current conundrum focuses on developers who sell their work through ThemeForest. ThemeForest licenses all code for WordPress themes and plugins under the GPL automatically, but does not follow the interpretation that images, CSS files and other creative assets must also be licensed under the GPL. Let me be clear: this is a generally accepted interpretation that is considered legal under the GPL. However, the WordPress Foundation takes a differing (and also legal) interpretation of the GPL, requiring that those creative assets share the license of the theme or plugin as a whole. As a result, the WordPress Foundation considers anyone selling their work through ThemeForest to be violating the WordPress license.

As a result, the WordPress Foundation will not allow those developers and designers who sell their work on ThemeForest (or otherwise do not comply with the WordPress Foundation’s interpretation of the GPL) to speak at or sponsor WordCamps. If you’re not familiar with WordCamps, they are the conferences that take place in cities all over the world, providing a face-to-face forum for the WordPress community. I’ve been involved with several (volunteering, speaking, etc.) and consider them an important part of the WordPress learning process. Jake Caputo, who has also been involved with numerous WordCamps, wrote a post last week about being informed that his involvment was no longer welcome.

There are a number of major issues with how the entire situation has been handled.

  • First, and perhaps most importantly, excluding members of the community over an equally valid interpretation of a legal document has to be considered problematic. This is the sort of action that leads to major splits in an open source community, as well as makes users less willing to rely on a piece of software’s stability.
  • ThemeForest’s users are being punished for something that is out of their control. They don’t set the licensing policy. Matt Mullenweg (the guy who initially developed WordPress and founded the WordPress Foundation) has repeatedly suggested that developers and designers move to other marketplaces that comply with the WordPress Foundation’s interpretation of the GPL. But there isn’t another WordPress theme marketplace with a similar level of transactions. Plenty of people make full-time livings through ThemeForest, but I don’t know of any WordPress developer making a full-time income by offering their work through another marketplace. (There are several who do very well offering themes and plugins independently, but many developers in this category have had their own arguments with the WordPress Foundation over the GPL.) It’s nice to say that “forgo[ing] profits for principles” is the right move, as Mullenweg responded to Jake Caputo, but we’re talking about putting food on the table in an entirely legal way.
  • Communication between the WordPress Foundation and the owners of ThemeForest has been demonstrably poor. Collis Ta’eed, the founder of ThemeForest, has written up a description of how the company has attempted to balance the WordPress Foundation’s interpretation and a need to protect its sellers. He makes it clear that he’d felt that the two organizations had opened up lines of communication and were working to find a solution, when the WordPress Foundation chose to again enforce rules about noncompliant speakers.
  • The overlap between the WordPress Foundation and Automattic (also founded by Mullenweg and the owner of WordPress.com) continues to be exceptionally blurry. During my time helping to organize a WordCamp, I saw firsthand that it’s not always clear who you’re talking to — whether they’re paid by the for-profit or the non-profit. That’s a dangerous way to run two very different organizations with two different goals. Whether or not it’s the case, that lack of distinction makes it seem like the WordPress Foundation has a problem with anyone making money from WordPress — except for Automattic.
  • The WordPress Foundation has failed to address the underlying reasons that ThemeForest uses a split license. On a fundamental level, it’s very difficult to distribute software under the GPL and still charge for it, because, legally, anyone can do just about anything with it (including turning around and giving it to someone else free of charge). Yes, that’s the reality of doing business with WordPress, but the ThemeForest license offers a middle ground that has resulted in developers and designers who would have otherwise worked on non-WordPress projects. Offering a little leeway creates a far more vibrant community overall.
  • Lastly, this isn’t nearly the first time that the WordPress Foundation has found itself in this position. There’s a certain appearance that the organization is attacking underdog developers at this point. I hate to wish a court case on anyone, but it’s reached the point where I want to see the GPL go to court and receive a ruling, preferably several times over, so that there’s a set of case law based on legal judgments on the situation.

All of this adds up to a platform that I am less and less comfortable using in my business. I can’t recommend WordPress in good conscience to my clients right now, particularly because I usually add a suggestion to go to ThemeForest to pick up a design. I am reluctant to commit too many of my own resources to it because I don’t agree with the principles that are being promoted. I guess, in a way, that makes me willing to forego profit, just as Mullenweg suggests.

There are plenty of other content management systems out there. I’d rather do business with an organization that I know will be able to continue offering their product under the same rules a year from now, that goes out of its way to be easy to work with and that is willing to discuss problems in a rational way. I run my business with respect for the freelancers and other individuals I deal with; I want to be sure that the people I depend on to earn a living get treated right by everyone else, too.

A Personal Connection to Envato

Obviously, if I’m willing to write this long of an article about the arcane nature of open source software, I probably have a horse in the race. In fact, I have several. ThemeForest is owned by Envato, a company that I am proud to have worked with for several years. I’ve written for FreelanceSwitch for four years, as of next week, as well as for several other Envato-owned sites.

I haven’t bothered to ask the WordPress Foundation if taking Envato’s money disqualifies me from speaking at WordCamps. Since I don’t sell any themes or plugins through ThemeForest, I should technically be in the clear, even though I get payments from the same source as people who have been informed that they’re not welcome to speak.

But I’m choosing not to speak at such events for the near future. I haven’t decided if I’ll refrain from attending entirely, though I’m seriously considering it. My reasons for doing so come in two parts. First, there are some great people I’ve had the opportunity to work with who are effectively banned from WordCamps and I’d rather not be a part of a community that chooses to think in terms of excluding those individuals. Second, the only reason that I don’t sell anything on ThemeForest is because I don’t have anything to sell. I’m bad at development and while I’m working on getting better, I’m not focusing on learning PHP. ThemeForest is an incredibly useful marketplace for both developers and designers, though, and I would be proud to be a seller there if I ever get decent enough.

I still think WordPress is a good platform and I expect to watch it thrive in the future. It’s far too late to even consider a different license for WordPress and I wouldn’t expect the WordPress Foundation to attempt it. Unless there’s a change in how the license is enforced, however, I’m taking this situation as a sign that I need to at least consider moving on.

Image by Flickr user Michael Dorausch