Yesterday opus of French webcomic Commit Strip was not the funniest ever, but certainly one of the most interesting. There’s a lot to say about those 2 guys, and the reactions I had after tweeting about the one I would hire were worth blogging about.
If I had to hire one of those guys, I’d took the one on the right. He’s a system administrator, which gives me a natural feeling of sympathy for him. And I love his “let’s code, release and share” state of mind to the “I’ll browse the Web and find someone who’s already done the job for me” one.
Things would be easier for me if one of these attitude were 100% good or evil. It’s easy to make first read assumptions when the most interesting part of the comic is what’s not written.
Does the guy on the left understand what he’s doing?
That’s the first question I asked myself when I read about the guy on the left. Or, to be honest, here’s what I thought: “this guy has no idea what he’s doing. He’s unable to code what he’s been asked to do, so he’s relying on someone else’s job. There’s a large chance he won’t understand how the script works, so he’s looking for an easy cut and paste tutorial”.
That may seem unfair from me. I got influenced by the wording used there: “I’m sure someone has developed a jQuery plugin that does exactly what I want”.
If this is the case, then he puts the whole project at risk. My sarcastically inclined mind and knowledge of the comic make me think “He’s working for a Web agency so he’s doing quick and disposable code”. I know that’s unfair. Some agencies do a great job with maintainable code, performance and accessibility.
But what if he’s a lazy crack?
I tend to value lazy people, they make awesome computer engineers. They’re great at building automated reliable things so they never do the same job twice.
So let’s say this guy is a kazy crack. He knows what he’s doing. He’s already released tons of jQuery plugins. His plan is to integrate the plugin it in a whole, well documented, well maintained framework. In the end, he’ll send the author a pull request with new feature and refactored parts.
This guy is actually focused on releasing something without reinventing the wheel. He’s relying on the community knowledge to save time with solving a problem someone already worked on. That’s how open source works baby!
Unfortunately, I don’t think he is that kind of guy. Because he’s looking for a plugin that does exactly what he needs, I’m sure he will use it as is.
What about the Not Invented Here syndrome?
The beard guy has the right state of mind, hasn’t he? He wants to code something and release it as an open source library “if it comes out nicely”. I love it, but as Jean-Baptiste Barth said on Twitter, it can also hide the not invented here syndrome.
Not invented here (NIH) is the philosophy of social, corporate, or institutional cultures that avoid using or buying already existing products, research, standards, or knowledge because of their external origins and costs.
We had no clue whether or not this guy had made prior research to find an existing library he can use or start from. Maybe he’s putting the whole project at risk because he has decided to start from scratch but did not evaluate the time it would take to do it.
That’s an important part of planning a project. A homemade solution has risks and costs that need to be planned before the whole project start, and you’re never sure how it turns out.
I’ll release it if it comes out nicely
Most companies I’ve been talking with about releasing open source code came with the same answer:
Releasing open source code is showing our knowledge. We can’t show uncommented, not perfect code to the world. Our image of technical excellence is at stake. Neither can we allocate time to fix bugs and maintain it for the community.
I don’t think it’s an acceptable answer. If Linus Torvalds had came with this state of mind, we’d still be using commercial UNIX all over the world. And the community is more about helping to fix things when they think it’s useful than asking for your time.
Chris Raethke settles the debate saying:
If not good enough for open source v0.9, do you want it in your codebase?
I bet you don’t, but you’re probably too much in a hurry running the race for feature to think about it.
Chris, still him, comes with a pretty nice conclusion, suggesting to pitch both solutions to the team and see which one to pick up. As a realistic open source contributor, I guess the answer lies somewhere in between.