How I Open Source | Hacker News Reader

How I Open Source

blog.jayfields.com

77 pointsdrtse410 comments

I agree and I've been trying to clean up some hacks just a bit (things like removing API keys that should have been in a config file from the start…) and put them on GitHub. Not because they're great and the world needs to know, but mostly because someone, somewhere, might come across it and get something out of it.

Though this difference between "open-source project" and "putting code out there" is where I'm not sure what companies/recruiters think about when they say "open source contributions is a plus". Most likely they'd love to see someone who is a core committer to an important project, but I would think that the truth is that not many developers have contributed significantly to a medium to major open-source project.

I contributed mainly to one project some time ago, but nowadays, I prefer to work on my own things even if they are much much smaller.

As someone who's done a fair bit of hiring, I'm happy to see anything out there at all. At least it gives me some real code to look at.

Of course, having contributed to (or better yet, created) a widely-used project is an even bigger plus. But something is usually better than nothing, unless that something is code so awful that it makes me not want to hire you ;)

How often have you been able to hire a core contributor or creator? I ask out of curiosity because it seems most of the OSS guys I follow are independent consultants, and don't fit the profile of being an employee somewhere.

While having started a widely-used project looks impressive, I'd much rather see a steady stream of improvements to existing projects from a potential hire than a bunch of their own projects that no one else uses. While the latter may tell me a bit more about how someone's design sense, the former tells me more about how well they work with other humans, which is much more interesting.

I've definitely had this hesitation before and, like with programming, the more I publish and open source things, the easier it becomes. It might not be perfect, but good programmers can figure it out without help or novice ones can ask questions and show you where you need to explain things in more detail.

I've always wanted the organized README file, the detailed CHANGELOG file, the pretty bootstraped github page, and the polished docs, but it takes effort to get there. The little details along the way have tripped me up. After creating 3-4 active projects now on Github, I've worked through most minor details, cleaned up my older projects, and raised the overall quality of all my projects.

That's a great article. I have made a similar experience, too. However, there's one thing I strongly disagree with. From the article:

> I have no qualms with walking away from projects, as I expect that if the idea is valuable, someone else will be happy to step up and take my place;

Up to here I agree. However, the article continues with:

> it's more likely that several people will step up and the strongest will survive - which is best for everyone.

To my experience, this is the #1 reason why promising projects die (by slowly converting to crap): The maintainer goes away, quietly, leaving everyone in confusion. I always thought this would happen only by accident (previous maintainer overestimates his/her free time). But I'd never have thought anybody would do this on purpose.

It is really minimal effort to drop a quick note about dropping the project and naming a successor.

Yep, look at Node.js when Ryan Dahl passed off the reins to Isaac Schlueter. The project is obviously strong as ever, and I think it probably helps that they're both at Joyent. So maybe the succession planning lesson learned here is to name a successor AND make it someone you can continue to regularly communicate with.

'Just get it out there, it'll be used or not.' I love this point: there's no need to try and hit perfection, just put it out there and if it's useful people will help you. That's the beauty of open source.

I think all this applies only to developer tools/libraries. There interested people can also help i.e. they find a bug and fix it and if they are nice, they contribute.

Projects for end-users tend to either have a corporate interest behind them, are ex-commercial projects, have a strong core developer team without which the project will die or just live and die unnoticed.

As in every project, if you think 90% is done actually less then 50% is done. Documentation, installers, etc. are all a lot of work. Try getting a new package into the major Linux distributions!

If you do not have documentation, installers etc. you won't get users and your project will be irrelevant - if you are lucky someone contributes, but most often everybody has his own pet projects in which they are emotionally invested.

This is great. I think the key point of this, is that you gain nothing by keeping your code squirreled away, but there is a very small possibility someone else might need something similar and reuse your code if you do put it out there.

Reply on news.ycombinator.com