There is a consistent thread in my career, other than not having been fired from a project since 2001. It is the repeated failure to carry an Open-Source project that deserves to be called more than an amateur attempt. I throw in the towel. I’m not going to breathe new life into my Hibernate-killing polyglot ORM framework for the JVM. And if I do, I won’t share it with the world. I have given up and given in, and I know exactly why it happened – or rather didn’t happen.
We’ve all heard and probably repeat the claim that any serious developer should boast an impressive portfolio of Open-Source work. I’m not talking about being a core contributor to the likes of Spring or the Apache foundation. If that were a prerequisite to landing a job, I think few of us would work at all. I mean the thousands of one-man-band projects out there on github in varying stages of abandonment. Merely showing your job is also your hobby doesn’t make you special.
My time and enthusiasm to program privately after office hours or during the holidays comes in waves. Sometimes it’s gone for a year. Same with my hobbies in theatre, music, and photography. I haven’t touched my cello in months and my wife didn’t complain. But like pot plants, software needs water and love, or it shrivels to oblivion.
French baguettes are baked in small and frequent batches because bread goes stale the moment it leaves the oven. It happens to code a lot quicker than you like. That makes it a liability. Chew on that statement, harsh as it sounds. If you tinker in multiple projects and share them with the world, you soon have a showcase that grows less useful every year.
Be warned that I speak with no authority on the subject, except for knowing how not to go about it. If you can tolerate my pontificating on the subject, here are my four reasons why you would code in your free time, only one of which I consider sufficient to share that code as an Open-Source project.
Fun
I play freestyle jazz with the same amount of skill and pleasure as I built Lego spaceships as a boy. Interpret as you like. As adults our hobbies too often become goal-oriented pursuits, which can take the fun out of them. Real leisure is also about doing things without becoming better at them. There’s nothing wrong with messing around with code for the sheer fun of it. But having fun is no guarantee that you produce anything good or useful or even that you get better at it. It just ensures you are happy about putting in the time. It’s necessary, but not enough.
Learning
They put you behind the wheel for your first driving lesson because practice is the best and sometimes the only way to learn. Hobby projects are great for turning your newfound knowledge into skills cheaply and safely – unlike parasailing. But without senior supervision and review, that code is not ready to be shared. If you pick and choose your own curriculum for teaching yourself, you go for whatever takes your fancy. A proper course prioritizes what’s important and covers topics that don’t seem useful or important to you at first. Hobby projects complement such training. They don’t replace it.
Recognition
As social beings we love to appear knowledgeable in the eyes of others. Recognition from our peers gives our sense of self-worth a positive boost, as well as our CVs. There’s nothing objectionable about a little ego polishing. Just be honest to yourself how much of it drives you. The warm feeling of recognition overlaps emotionally with the sense of fun. But private fun is more reliable than the satisfaction that depends on other people’s approval. Vanity is a dubious motivation to undertake anything, and in Open-Source it is a particularly poor indication for success. You can’t bluff your way in. It’s a meritocracy where recognition comes only after hard work and consistent quality. There is no overnight success.
The personal itch
I’ve been talking about code and coding when I should have been talking about a software product, not just practical snippets and recipes. Products have life cycles. They’re the work of grownups, with work being the operative word. That work needs to scratch a deeply personal itch if you commit to it for the long haul without pay and a small sense of success. You must be convinced you’re working on something useful. Only then is it likely to benefit other people too. The incentive to share comes naturally then. Sure, you need to have fun and be appreciated, but you must eat, promote and like your own dogfood before anything else.
Longevity is just as important as quality. Frameworks must support Java records soon, as they previously had to deal with lambdas, modules, and generics. Sorry, but the work is never done. That’s what makes the motivations of fun, learning and recognition inadequate. Their goals can be completed. You can be done with them. If those three are your only drivers, you can shout “mission accomplished” any time and abandon the project regardless of the state of your code. And you will.