

How I Open Source - drtse4
http://blog.jayfields.com/2012/05/how-i-open-source.html

======
Timothee
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.

~~~
autarch
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
;)

~~~
taylonr
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.

------
askedrelic
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.

------
vog
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.

~~~
zafriedman
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.

------
jszmajda
'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.

------
tobias3
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.

------
icco
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.

