Tips for Maintaining an Open-Source Library

https://segment.io/blog/tips-for-maintaining-an-open-source-library/

by ianstormtaylor • 13 years ago

42 9 13 years ago

segment.io

emaste• 13 years ago

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

ivolo• 13 years ago

g0od call, it's updated.

dave1010uk• 13 years ago

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.

ianstormtaylor• 13 years ago

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.

Aga• 13 years ago

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/

Ixiaus• 13 years ago

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.

pseut• 13 years ago

Some more advice: http://producingoss.com

csense• 13 years ago

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.

dhruvaray• 13 years ago

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)

Tips for Maintaining an Open-Source Library

Related Stories