Tips for Maintaining an Open-Source Library | Hacker News Reader

Tips for Maintaining an Open-Source Library

segment.io

A CHANGES file is hugely overlooked by many projects. I've only recently started using it, but it's a great way to help other developers get a "gist" for what the latest version includes!

Depending on your platform, a DEPS file is pretty useful too; for my Python projects I've got a DEPS file that is just a "pip freeze > DEPS" output. It's then loaded into the setup.py - it serves two purposes, easily recognizable by a developer and also used by the package for its dependencies.

I keep the latest version in a VERSION file that is loaded by setup.py for its version.

I can't say enough for README files that are kept up-to-date and full of GOOD information. It really doesn't take too much time either.

When I first started downloading and compiling a lot of open-source packages (in the early 2000's), semantic versioning was a pain point for me as a user.

Mainly because download sites would sort names alphabetically, so e.g. 1.11 would come after 1.0 and 1.1, but before 1.2, 1.3, ..., 1.9.

The instinct is that the latest should be at either top or bottom, you see that numbers are increasing, so you scroll to the bottom of the list, and end up downloading the obsolete 1.9.

Another one... Wouldn't it be a good idea to keep the repository private/local until points 1, 2 & 3 are reasonably well nailed down? Would probably make the process of contribution a bit more smoother.

We probably erred on the side of caution (in terms of drawing traffic) with our first stint at open source contributions (https://github.com/dhruvaray/backbone-associations)

Do people use pull requests for closed source code within very small teams (less than 5) too? I'm wondering if the QA gained would be worth the extra administration time.

Yeah we actually do that for some of our code. Usually when one person is editing some code that is typically outside their comfort zone, so they want to make sure the usual maintainer looks at it before it gets merged in.

Why yes! I've used it (or Gerrit code review [1], to be precise) even in two-man projects!

As important as QA is to keep others in the project aware of the latest changes.

[1] http://code.google.com/p/gerrit/

Also, "Make sure your chosen license is clearly stated"

g0od call, it's updated.

Some more advice: http://producingoss.com

Reply on news.ycombinator.com