Open Responsibility

I like to be very “open”. I write about my ideas and experiences and I share code projects on GitHub. There are many reasons for this. High on that list are the improvements I gain as a professional in this industry.

Sharing Code

Some of my projects like Pikaday are very mature. I’m keen to see them adopted and still have interest in (if not time) evolving them further. Projects like Nestable are proof of concepts that I believed worthwhile enough to publish. I’m happy to share partial solutions; I’ve repurposed plenty of open code myself and saved hours of reinventing the wheel.

The majority of my code can be used with the BSD & MIT licenses. That means, for all intents and purposes, it’s free. I have no responsibility or control over how you use it. That also indicates I’m unlikely to respond to emails.

Tech Support

I have a code repository that exists to support an article I wrote for Smashing Magazine on implementing off-canvas navigation. This is a close look at an intricate aspect of CSS. My demo is just that; a demonstration. One example, not the definitive example. Certainly not a mindless plugin that will do everything tangentially related and more.

I get so many emails — “I’m using your plugin, how do I X?”I don’t know how to reply. It’s not a plugin. It does what it does. Now don’t get me wrong, if someone politely asks me to explain further or is not entirely sure what they’re doing is right, I’ll try and find time to answer or point them in the right direction. But the one-liners “how do I […]?” just piss me off. What am I suppose to do, Google it for you? code it for you?!

I’ve come to the conclusion that I shouldn’t feel guilty ignoring these emails. If I wanted to discourage any kind of contact I wouldn’t publish openly in the first place.

There’s an etiquette when asking people to give up their time for free. I don’t know if exact rules exist but at least be specific, be polite, be succinct, be conscious of how much you’re asking for. Documents like Nicolas Gallagher’s issue guidelines set out very simple and direct instructions for contribution. I need to adopt something similar. I’m sure few people will read it but at least I’d have a URL I can link.

Project Legacy

On the flip side of this I have projects I once actively promoted that I no longer touch. I developed Socialite.js to stop social media buttons affecting the initial page load; a huge perceived boost in performance. Nowadays I no longer have a mandate to plaster websites in yesteryear’s marketing fad. I haven’t touched Socialite in a long time. It still works, but more and more edge cases are cropping up at the expense of frustrated developers.

The BSD & MIT license doesn’t make me feel any less responsible every time I ignore a new ticket in the issue tracker. Taking the project down is too extreme as I believe it can still be useful. I’ve added a notice — “Socialite is no longer under active development” — but is this enough?

Taking Payment

I deliberate these concerns because I’m currently working on a project that I could theoretically charge for. I often buy licenses to use good code but I’ve never been on the other side. I can write a license that will ensure profitability vs time invested in support but if I struggle to handle the responsibility for free stuff, what will happen when money is involved?

I’ll always share projects and maybe one day I’ll charge for them too. As funny as it sounds I just need to stop caring so much. I’m putting too much onus on myself. I’m taking the collective demand for attention and manifesting that as a single overwhelming opinion.


Follow @dbushell on Twitter
Return to Blog