Back in 2007 when I first announced my masked input plugin, I had no idea what I was doing. It was early days in jQuery and still very early in my career. I was just trying to give back a little bit for all that I had been given from open source software. I had no idea that over 7 years later I would still be working on this project. At the time I needed this, I built it to suit just what I needed and put it out there. That's how this OSS thing works. right?
Why am I telling you all of this? Is this a humblebrag?
I'm not telling you this to brag at all. I need you to understand the scale of it all - it's a clue to the source of much of my anxiety. I'm still shocked when I see those numbers because I have no idea how it happened. No, I'm telling you this because it's time to tell a story of what happens when something gets bigger than you and how I'm handling it.
Grab a snack, this might take a while.
I didn't quite realize this going in, but it takes a lot to maintain a project long term. This is only magnified by the number of people actually using it. Those people are using this as part of a product they are building and each has their own unique requirements. Given my role in this, I feel obligated to provide a certain level of quality. Unfortunately, if I were to build in every feature that was requested, then I would end up with a kitchen sink project. I'm sure you've discovered these in the wild. They have a ton of options and go out of their way to accomodate everyone while sacrificing usability/performance/stability for the majority. In the world of web library development, each new feature comes with a large future cost in effort to maintain it.
There are a lot of browsers out there to test on. Each one broken in it's own special way. At present I test on desktop OSs: IE 8-11, Chrome, Firefox, Safari. Then there are the mobile browsers... Oh, the hell that mobile browsers cause. I wrote this before there were even smartphones. Now I'm trying to make sure it works at least on iOS and Android. It's safe to say I take pause when a new feature request comes through. That's a lot of work to make it work everywhere given that I have to contend with weird stuff like this.
At this point, it's worth sharing with you that I have a really hard time telling people "no". I have such a hard time with it, that for a while I just didn't. Issues suggesting features and pull request came across my inbox. I wasn't 100% happy with them, so I would just ignore them. Deep down I knew that ignoring them was bad, but somehow I was just hoping that it would all go away. Of course you know how these things go - problems won't magically resolve themselves. So when legitimate issues popped up with bugs, I continued to ignore them because of the other open issues before them. Several times I tried to get back into it only to get upset about the state of the code. Everything was just in deadlock.
A lot of events had happened around this time in my life and it was all overwhelming. Really though, there are always going to be distractions from free work. It's funny, since I've started this project I've had two children, sold one house, purchased another, changed jobs 2 times voluntarily, and got dumped on my ass once because an employer didn't play nice with the IRS. This product has been wearing on me for a while and the words you're reading are basically what my close friends and coworkers have been hearing from me for years.
About 4 years ago I put out a bit of an SOS. That was the first upswing in series of akward cycles of disgust, acceptance, small effort, tiny release, finally ending with denial induced procrastination - "I just did a thing, you should be happy with the thing. I'll pick this up in a few months." Each cycle I would get maybe 1/4 of what needed to be done completed and then fall off. This is how I ended up with nearly 90 issues out there. Ninety. Issues. The project only has 430 lines of code, how can it have 90 issues?!
This is open source and it's all out in the, ahem, open. There sat 90 fingers pointing at me for the world to see. This guy is failing. Every time I would open up my issue list, there was more. For one person it felt pretty unsurmountable. At this point I can just hear you saying, "It's open source, you don't have to do it alone. You should have just accepted the pull requests and moved on." The problem lies above where I mentioned that I felt obligated to meet some self perceived level of quality. Very little of the code being sent my way was meeting that imaginary quality bar. In reality, the problem was me. I had failed to provide any feedback. If something wasn't right then I should have responded and tried to set some expectations about what I wanted the final outcome to be. Instead, I just let the valuable feedback and code sit there and rot.
It's silly for me to expect someone else to play an open source game with me when I haven't told them the rules. Heck, I didn't even know the rules. I just knew when the solution didn't feel right or complete. You can't run a project like that. It doesn't work and I think I've done a good job at proving that. I was about rock bottom mentally on this project and the way I saw it, I had 3 options:
- Call it quits - Just throw my hands up and walk away. Put a note on the README letting everyone know that this project is dead. I seriously considered this one, but I felt like leaving when the project was in such terrible shape would be a huge disservice to the many existing users.
- Hand off the project - There was already a couple of well established forks out there, so this never felt useful. The people I would have handed it off to were already well into building their vision of this widget. When I looked at the forks I was impressed with the stuff they had done, but it didn't feel like something I would want to use.
- Suck it up - Go through the long process of wading through the issues and pull requests and try to make sense out of the madness.
It wasn't until I was on the other side of the pull request that how this process goes finally clicked. I wanted to add a small feature to elixir and stumbled on their excellent document on contributions. There it was, everything I needed to know about getting my code accepted. I knew exactly what was expected of me and I followed the rules laid out in that document. Within no time my pull request had been accepted and that issue was closed and gone. Huh, so that's how it should work. That was a smooth process.
With the help of Jared and the encouragement from several friends, I decided to take option #3. It took a while and I stalled a few times, but we went through each issue; triaged it; set up a plan of attack; slowly worked through the bugs, feature requests, and pull requests; and finally released version 1.4. It was hard because I had to say "no" several times. It was hard because I had to respond to several year old issues and say "I'm sorry this has taken so long." It was hard because I pretty much wanted to be doing anything but staring at the mess I had created.
Inspired by the contributing document I mentioned above, I've borrowed heavily from it and added my own contributing document to the project. I'm working to make it easier to have an answer when a feature is requested or a a pull request is sent over. Had I established these guidelines early on, most of these issues would have been as effortless as my experience with the elixir project. There are still some outstanding issues and I'm hopeful we can move those forward and resolve them too. Most of all, I'm hopeful that I can get this project to where I can stay on top of the requests without a massive amount of effort. If not, well there's still option #1; at least I'll know I tried everything I could to keep it going.
For those of you putting a project out there for others to use, don't let any of this scare you. You won't have to worry about any of this up front; just build something awesome and share it. If people start using the thing you've built and want to give back, take some time to really think about the direction you want the project to go. Put that into words and make sure everyone knows what to expect. They might not like your rules, but at least they'll know up front if they want to play.