I do a lot of work on code that is open source and I consider myself very lucky in being able to do that. I try to open source as much stuff as I can, but not everything makes the cut. There are a lot of things that never see the light of day beyond the project in which they were created. That’s ok, though. Not every piece of code I write should be written so that others can use it – even if the idea is reusable.
I Don’t Care About Your Needs… Yet
One of the most important lessons that I’ve learned in software development, is that I need to solve my own problems first. This sounds extremely selfish and completely counter to the idea of open source and giving back to the community – and it is.
But once again, that’s ok.
Very few of us are paid to work on open source projects. It is a rare thing, indeed. Even if we are able to work on open source for a company or client project, it is usually done as a means to solve the current project’s needs.
When I sit down to work on my client projects, for example, I don’t set out to write open source things that are unrelated. Rather, I intend to solve the problems and implement features and solutions that my client needs. When I am solving my client project needs, I usually don’t care about how the code I am writing will affect other developers that might want to use the same code. I am concerned with getting my client project right. Other people and their needs will have to take a seat and wait their turn.
I Might Care About Your Needs, But Not Your Code
Sometimes the open source world and the client project overlap. When these worlds do overlap, I may take the time to write code in a way that is re-usable by other people. I try to open source this kind of code whenever I can, and when I do this I do try to keep other people in mind.
Keeping other people in mind usually doesn’t change how the code looks, though – at least, not at first. The single largest change that this causes in the initial stages of writing open source, is documentation.
People need to know how to use my code – how to get started and what methods to call, when. This has a much larger impact on others than, say, having the most elegant or flexible API to work with. If no one knows how to use it, the API design doesn’t matter much.
Ok, Now I Care About Your Code
When (if … and that’s a big if – I release a lot of open source code that zero other people ever use) someone else finds something useful in what I’ve written and it doesn’t meet their current needs, then I care about what their needs are. If it is something that I can change and would make sense within the focus of my project, then I may add it or accept a pull request for it. Documentation changes are always welcome, too, as getting other people’s perspectives on what needs to be known will help others down the line.
Eventually, I will care about other people’s needs in my open source projects – but it takes a while to get there.
I’m Solving My Own Problems, Not Yours
If you look at the code that I have released as open source recently, there is very little that is new. Sure, it may be a new project or a new spin on an idea when one particular person looks at it. But the truth is, most of the ideas that I am open sourcing have been baked in to my systems for a long time – but baked in as part of that system, not as something re-usable.
I wrote a MongoDB database migration framework, for example. This is definitely not a new idea to the community or to me. I wrote the first version of this more than a year ago, but rewrote it when I needed it in new projects recently.
Authentication and authorization for NodeJS web apps? Again, not a new idea. I used other people’s code for a long time, until the frameworks I used did not meet my needs. I wrote the first version of my authorization library over a year ago, and baked it in to my systems. The authentication library was new to me for NodeJS, but something that I had done a dozen times in .NET and Ruby. Both of these got fresh rewrites when I needed them in multiple places.
All of my most successful open source projects have come from me solving my own problems, first. Once I know how to solve a problem and I see that I am doing the same thing in multiple places / projects, then I look at making the solution re-usable. I’m lucky in that I get to open source most of my solutions like this, but not everyone has that luxury (or wants it).
You Should Solve Your Own Problems, Not Mine
Solve your own problems, first, for the current applications and systems.
Don’t set out to write frameworks and libraries the first time you run in to a problem – or even the second time. Wait until you see the need for the same solution in multiple projects, before you try to extract something reusable. Your extracted libraries and frameworks will be much better off, having done that.