Why You Should Consider Releasing Code

Wednesday, December 31st, 2008 @ 10:28 am | filed under: Code Releases, Examples, Tools

I posted the other day about Ian Collins’ Moo-ish Template, a scaffold for putting together your own JavaScript library organized as MooTools does (and as I do for Clientcide). But let me tell you why I think you should.

The Costs

Releasing code is a pain. Seriously. It takes a ton of time. Here are the things you have to do when you release code in order to do it well:

  1. Write the plugin – this means writing it so that others can use it, extend it, customize it. Writing a plugin for other people to use or even so that you can use it again in a different context takes some extra work and foresight. Putting something together might take 30 minutes to write, but writing it so that it makes liberal use of Events, Options, and other conventions means spending a little more time imagining how it might be used, but only a little bit more actual code.
  2. Write the documentation.
  3. Write tests – JSSpecs for automated tests or use my Unit Test Framework for interactive tests. It often helps to create the test as part of the development so that as you work on your plugin you’re using your test environment to see if what you’re authoring is working (a.k.a. test driven development).
  4. Run the tests in all the major browsers.
  5. Fix any browser issues you encounter – count on IE being the pain it always is.
  6. Create a demo – the test you created might suffice; I use my wikitorials which serve as both tutorial and demos.
  7. Write a blog post to release it and describe it to your userbase – I don’t always do this.

As you might guess, a plugin that takes 30 minutes to author might take 2 hours to release. The ratio works better for bigger plugins. A plugin that takes 4 hours to write still probably only takes 2 hours to release.

The Benefits

The big benefits to releasing your code are mostly long-haul kinds of benefits. It’s always faster to just write what you need, use it, and move on. It’s only months later that you see the benefits of spending that time it takes to release something.

These benefits include:

  1. You help MooTools (or whatever framework you use) – the more people writing and releasing code there are, the more useful our framework of choice becomes. I’d like to think that all the code I release for MooTools helps people who are considering using it vs. some other framework more comfortable with choosing MooTools.
  2. You are creating a tool-chest of plugins and tools that you can take with you to your next project. This becomes increasingly valuable over time.
  3. Your clients have a piece of mind knowing that you will continue to manage and maintain a codebase that they rely upon. They might hire you to implement a handful of features, but knowing that the code on which those features are based will continue to be maintained – at no cost to them – will make them more comfortable with all your work.
  4. It will bring clients back to you. If they know that you’ve released a dozen plugins since you last worked with them and that you continue to maintain and improve the things they are already using, they’ll look to you when their needs change and grow.
  5. It brings you work – as much of a pain as it is to publish your code, you’ll find that it gives you some authority, if on no other subject than just your plugins. The more tools in your tool-chest the more of a master crafts-man (or crafts-woman) you’ll appear to be.
  6. It brings you traffic. If you have a site where you release your code and blog about it, it keeps people coming back. Someone who is borrowing your tool-chest wants to know when you add more tools or fix old ones and they are looking to you to learn how best to use it. On Clientcide, the download page, docs, and demos get as much traffic as the blog. I don’t put ads on these pages, but it brings me work (see previous point).
  7. Finally, it just feels good to contribute back to the community. This seems like a small thing, but it can be very fulfilling.

Defraying the Costs

The effort involved in writing something for release requires that you remove yourself from your current task. I do a lot of consulting and when a client asks me for something that I think would be useful to others or even useful to myself again in the future, I have to put the client’s needs aside and think about the plugin for its own merits and uses. The client’s requirements are a subset of the possible requirements for anyone that might want to use it. I often find myself writing three or four plugins to meet the client’s needs. I might write two or three small, stand-alone plugins, another plugin that puts all those together into one single managed interface, and then extend that to create a customized version for the client that adds esoteric functionality that no one else would ever really need. If instead I just wrote the client (or my own project) needs, it might be much easier, but far less reusable.

The way I pay for releasing my code is to get my clients to pay for it, and they are almost always happy to do so. Here’s how it works:

A client comes to me and wants features x, y, and z. I already have plugins for x, and y, so those won’t take any time, and z is going to take 8 hours to write, and 4 hours to release. If I had to write x and y, too, it would take, say, 20 hours to complete, but because I already have those, I am able to bill the client for 12, even though it includes me releasing the plugin.

Now consider if the client needs features a, b, c, d, e, f, and g, but I only need to author g. I’m telling the client that I can give them everything for about 12 or 14 hours of work, which is a steal, because previous clients paid for features a-f already.

The benefits my clients get are pretty big. They get functionality from previous work basically for free, the new functionality I author gets released, which means that other people are using it and finding bugs for them and then I’m fixing those for free and they can just download the library again to get that benefit. Plus, though it may sound like a small thing, it feels good. They know they are helping me get the next client by letting me take my work with me and that they are helping the framework that they now depend on, too.

If you look at my list of what I have to do to release a plugin, here’s how it breaks down for the client:

  1. Write the plugin – required either way, but doing it in a general context takes longer
  2. Write the documentation – depends on clients, but most will want this anyway
  3. Write tests – may be required, but this is “invisible” to the client, who just wants you to make sure #4 works
  4. Run the tests in all the major browsers – required for most clients, though perhaps list of browsers vary
  5. Fix any browser issues – required by the client
  6. Create a demo – not important to the client
  7. Blog post – irrelevant to client, mostly

So most of the tasks that go into releasing the code are things the client wants you to do anyway.

I should point out that I never really implicitly or explicitly bill my clients directly for the time it takes me to do the items that they don’t require (the blog post for example). My consulting rate is rather standard for the industry and the extra time I spend doing the things on the list above that aren’t interesting to the client are things I do between jobs.

Why You Should Release Code if You’re a Business

What if you’re not a consultant? What if you’re a company who isn’t looking for work the way I am? You still get a lot of benefits from releasing your code.

  1. You still are helping your framework of choice, which is no small contribution and, considering your dependency on that framework, something you should try and do whenever you can. You lend credibility to that framework and only strengthen it’s standings by endorsing and supporting it.
  2. By encouraging your developers to go through the process of writing their code for release, you get more reusable code. The overhead you pay for writing documentation and tests pays off when you need to use the code again, the same as it does for my clients.
  3. You create a user base for your code that essentially are people you want to hire. What better recruiting device could you hope for!? If there are hundreds or even thousands of users out there using your code and you announce on the blog that they are all watching that you need to hire someone who can use that code base, you’re going to get a lot of qualified resumes. This value is huge.
  4. You’re more likely to recover when you lose an employee. If they’ve built into their development cycle the act of documenting and testing all their code (or even a subset of it) and they leave, you’re more likely to be able to cope with their departure, esp. if you can just hire someone from those making use of it to replace him/her (see point above).
  5. You get free testing and bug fixes. If you release a plugin and people use it, they’re going to use it in ways you might not and find issues that you haven’t. This amounts to free QA. A lot of times you’ll get a patch that fixes the bug for you, which is free development. The people who send you patches are the ones you want to hire, by the way.
  6. You get some stature in your community for being a technology leader. Nothing tells engineers looking for jobs and competitors looking for weaknesses that you’re on your game like telling everyone that your code is so awesome that they should use it.

An Invitation and an Offer

So if you’re a contractor or a business who is using MooTools (or even if you aren’t) and want to release your work, I have two opportunities for you.

  1. If you put your code together into a MooTools repository (as with Ian Collins’ Moo-ish Template) and the code is good stuff, I’m happy to include it as a repository here on Clientcide (at least until the MooTools plugin site is ready). You still have to write your unit tests, publish your code, and write your docs, but I’ll do the rest if you don’t want to.
  2. If, on the other hand, you have a desire to do this stuff yourself (which would be my preference), I’ll give you all the tools you need. The docs engine, the download builder, the wikitorial, even my blog template.

So what are you waiting for? Get busy!

2 Responses to “Why You Should Consider Releasing Code”

  1. Nick Carter Says:

    I’ve been a fan of OSS for a long time now, and I’m now able to contribute which feels great. Wanted to share my thoughts on the subject and chime in with some recent experience.

    Since I wrote JazzRecord (www.jazzrecord.org) and released it, I’ve had a few folks correspond with me. I’m getting free testing and opinions. They’ve helped me find problems I probably wouldn’t have found on my own for some time. I wrote this lib for fun and as a challenge, and to know its of use to someone else is really the biggest treat.

    Just as background: JazzRecord is a JavaScript port of Ruby on Rails’ implementation of ActiveRecord ORM that allows you to work easily with sqlite databases in Gears, AIR and Titanium currently.

    Writing automated tests (I’ve been using JSSpec) is hugely helpful. Though I need to expand my tests to cover new issues we’ve recently uncovered, (and new features being added) I’ve caught several mistakes I’ve made when fixing other bugs thanks to automated testing. Prior to my current job I hadn’t written tests regularly, and re-wiring my brain for that also helped a lot. Nice, readable syntax in JSSpec and the mentality of BDD vs testing detailed internals also helps.

    After first coding a project, especially something as large as JazzRecord, keeping documentation up-to-date is probably the biggest challenge. It’s also the easiest thing to postpone, but having good documentation is another extremely important part of releasing a largish project.

    JazzRecord is currently a MooTools project, but will soon be made independent from any other library.

  2. Ian Collins Says:

    Great post, Aaron.

    I’d like to add that anyone planning to release a Mootools plugin or a codebase that sits on top of Mootools (like Clientcide) should really make sure to have a well-formed scripts.json file that maps all of the internal and external (to mootools) dependencies. One good way to make sure this works is to test your code using Aaron’s Mootools Unit Test Framework, as it needs a good scripts.json file to function.

    Having your dependencies mapped will make it much easier for other developers to use your code, especially if they’re generating JS lib files dynamically (as in Mooish).