Community-Run Conferences: The Most Bang for Your Conference Buck

Unconference Scheduling

I recently had the pleasure of attending Open Source Bridge and noticed several factors that made it an incredibly useful and enjoyable conference to attend. Open Source Bridge is an annual conference that takes place in Portland, Oregon (just like OSCON). It covers a variety of topics related to open source software, also similarly to OSCON. But while a full-access pass to OSCON runs about $2,000, a ticket to Open Source Bridge is $300. I love community-run conferences!

Full disclosure, I received a press pass for Open Source Bridge. (I’ve also received free passes in the past to other conferences I might reference in this post through volunteering, sponsorships, or client relationships.)

Community-run conferences are a much better opportunity for many people than many other types of events. Don’t get me wrong; there’s plenty of value to be had at mega-conferences and other types of events, as well. But considering the lower prices associated with community-run conferences, I always come away feeling like I’ve gotten so much for my money. Here’s why.

Community-Run Conferences Have More Room for Dissenting Opinions

The voices you hear at big conferences are often those speakers who are well-established authorities within their specialties. Obviously, big events need speakers who the widest possible audience will recognize in order to sell tickets. But when you have the ‘official’ opinion up on the stage, it’s harder for a speaker with a dissenting opinion to get on the schedule. The decision may be as simple as "We’re covering that topic already, so why should we have a second speaker discussing the same material?"

But that process does mean that different points of view are automatically excluded. The same doesn’t hold true at a community-run conference. Because a community-run conference almost always looks to the community first to choose speakers, there are more opportunities for diverse opinions:

  • Community-run conferences are generally more welcoming to newer speakers, including those with very different perspectives from the status quo.
  • Community-run conferences don’t have to toe the sort of party lines that a company-run conference must. This might explain why all the major hacker conferences are actually community-run events. Even big sponsors only have a limited impact on what can be said at a community-run conference.
  • Community-run conferences can afford to take risks on niche topics that may only appeal to ten or twenty people out of the entire set of attendees. Big conferences have to fill rooms to make economic sense.
  • Attendees at community-run conferences are more likely to pay for their own tickets out of pocket, so they don’t have to justify a particular event to a manager who controls the company budget for conferences. In turn, that means that community-run conferences can afford to offer more sessions on non-business topics.

The sort of variety that a community-run conference offers is more fun (at least for me). I’m far more likely to wind up at a session covering something I know very little about but that will dramatically change the way I see a particular issue. One of the first sessions I attended at Open Source Bridge, for instance, was on OpenMRS — an open source software project I was entirely unfamiliar with — which offers open source medical record management software. I chose the talk because I’m interested technology and health, but I learned a great deal about the problems international open source projects face, how a project can create software that’s usable in places with limited power and internet access, and even the unexpected localization issues that a hospital in Somalia might have as opposed to a hospital in Kenya. Perhaps more importantly, I got a very different perspective on open source technology as a whole that I can already tell will influence my own work.

Community-Run Conferences Have More Opportunity for New Connections

The argument that smaller conferences are easier to meet people at than their larger counterparts seems counter-intuitive. But large conferences are overwhelming even for the most outgoing people. We’re more likely to find a few people to hang out with at a time, to provide a buffer against the thousands of attendees at a conference like OSCON. It’s a paralysis caused by too many people. Personally, at particularly large conferences, I tend to find a "conference buddy" who I cling to to make sure I don’t get washed away in the sea of humanity.

At smaller conferences, however, I’m more likely to go around and introduce myself. I noticed at Open Source Bridge that I knew a large number of attendees and, as a result, I felt very comfortable and was better able to introduce myself to new people. After all, if I were to encounter a problem, I could always retreat to talk with people who I already knew.

Those connections occur outside of the actual length of the conference, as well. Conference organizers have varying levels of passion for the events they create. On the less passionate end of the spectrum, those individuals who are paid to organize particular conferences probably care about the events they manage, but not to the point where they’re talking about their next conference constantly. In contrast, someone organizing a conference out of sheer passion is going to tell everyone they know about the next event. Even the problems will be more visible, because that organizer’s friends will get to hear every last detail about the argument with the venue staff (whether anyone wants to or not).

The community is more long-lived as a result. Rather than moving on to the next conference at their employer, the organizer of a community-run conference’s next event is likely to be either next year’s conference or a closely related event. The organizers can pull the community along, maintaining excitement throughout the year between conferences.

Community-Run Conferences Have More Room to Experiment with New Improvements

A code of conduct seems like such a simple thing. And, yet, many large conferences of every type seem to struggle with implementing such codes.

Of course, there are community-run conferences without codes of conduct still. But many are more open to the idea of adding on a code of conduct — and seem more willing to adopting an existing, proven code without feeling that they need to develop a new code entirely from scratch. Those communities who aren’t willing to add such codes, well, that information can be valuable, too.

Because a community-run conference has the ability to quickly evolve from event to event, such conferences have more opportunities to experiment with better practices. As a for instance, when attendees registered for this year’s Open Source Bridge, they each had the opportunity to choose between three colors of badge lanyards: blue, yellow, and red.

  • A red lanyard indicates that the wearer does not want their photo taken at all.
  • A yellow lanyard indicates that would-be photographers need to ask before taking the wearer’s photo.
  • A blue lanyard indicates that the wearer is comfortable with having their photograph taken at the conference.

It’s a simple visual cue that can make a world of difference in making a wider variety of attendees comfortable with a particular event. There are a whole host of reasons that people may not wish to be photographed even if they’re at a public event. The default for most events is that everyone who happens to be carrying a camera (which you can read as all of us) can take photos and even recordings of anyone who happens to be at the event. I’m not entirely sure how this became the norm, but it’s not actually a reasonable approach. Event organizers may ask for a bulk permission to photograph or otherwise record attendees, but other attendees don’t usually take any steps to make sure that their photography subjects are comfortable with the situation.

This year’s lanyards aren’t Open Source Bridge’s first experiment in providing visual cues about appropriate behavior. Last year, the conference offered stickers for people to place on their name badges to express photography preferences

I can’t categorically state that lanyards are the best way to communicate these sorts of preferences; the only way to figure out such factors is to run an experiment or two. Community-run events seem more willing to do so, if only because the logistics of testing a new approach with a few hundred attendees is far easier than with a few thousand. Even better, most community-run events are put together by passionate people — and passion is rarely exclusive. If you are willing to do the hard work to bring information about your topic of choice to a wider audience, perhaps you’re also more willing to figure out the mechanics of running inclusive events.

Support Your Local Community-Run Conferences

I’ve always been lucky to be parts of communities where community-run conferences happen regularly. I grew up going to conventions for various bits of science fiction and fantasy fandoms. I used my student status in college to get cheap passes to all sorts of conferences (including a ton of writing events). When I started learning more about technology (especially programming), I went to BarCamps and other unconferences, as well as other small community-run conferences of a more traditional nature.

I’m happy to pay money for these sorts of conferences, but it’s also important to support them in other ways. Even small conferences take a ton of work, especially when they’re first starting up. Helping on even basic tasks like setting up chairs in a conference space is good. Open Source Bridge ran smoothly because around 70 volunteers put in their time. Some of those volunteers worked for months to handle every detail of the conference; some put in a few hours of work in exchange for a free ticket. Either way, they made the conference possible.

Especially if you come from a community that doesn’t have a strong tradition of organizing its own conferences, consider what you can do to volunteer. You never know — you might wind up organizing one of those community-run conferences yourself.

Image by Flickr user Reid Beels

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.