Ask Slashdot: How Do You Assess the Status of an Open Source Project? 110
Chrisq writes: "Our software landscape includes a number of open source components, and we currently assume that these components will follow the same life-cycle as commercial products: they will have a beta or test phase, a supported phase, and finally reach the end of life. In fact, a clear statement that support is ended is unusual. The statement by Apache that Struts 1 has reached end of life is almost unique. What we usually find is:
- Projects that appear to be obviously inactive, having had no updates for years
- Projects that are obviously not going to be used in any new deployments because the standard language, library, or platform now has the capability built in
- Projects that are rapidly losing developers to some more-trendy alternative project
- Projects whose status is unclear, with some releases and statements in the forums that they are 'definitely alive,' but which seem to have lost direction or momentum.
- Projects that have had no updates but are highly stable and do what is necessary, but are risky because they may not interoperate with future upgrades to other components.
By the treating Open Source in the same way as commercial software we only start registering risks when there is an official announcement. We have no metric we can use to accurately gauge the state of an open source component — but there are a number of components that we have a 'bad feeling' about. Are there any standard ways of assessing the status of an open source project? Do you use the same stages for open source as commercial components? How do you incorporate these in a software landscape to indicate at-risk components and dependencies?"
Re:Yes... (Score:4, Informative)
I have to presume OP meant "Free and Open Source", as opposed to just Open Source. Free, open source software is a particular subset of open source. There are lots of commercial open source products out there.
In my opinion, the best way to tell whether FOSS software is reputable and support will be available is to determine as best you can who, and how many, have adopted it.
OP should realize that in the world of FOSS, support is usually provided by users, not necessarily the core group of coders. If they aren't willing to dig for support on issues, maybe they should go to commercial software.
Here's how my team handles it... (Score:5, Informative)
0) If the project does what you need today, USE IT. Don't get so bound up in "future-proofing" your technology stack that you get paralyzed looking for "the perfect product that will do exactly what we want forever and never let us down."
1) Define your standard software stack. Mandate that all software written internally using open source components use these standard components & versions, or coordinate making a new version available to all projects if there's a particular new feature of a new version that is absolutely mandatory;
2) Always, always, always, download source for the version of the package you're installing (even if you just grab binary-only distributions to install & run), and archive it for posterity in some location YOU control and backup - DO NOT rely on "the internet" to help you find an old version of software; this allows you to fix (or hire someone to fix) any problem you have down the road in case of real critical issues where no active project maintainers can be found/hired/worked with.
3) Every few months (we shoot for ~6 months), review your stack and grab the latest versions of each component and make it available in your dev / testing environments;
4) If a component starts getting stale (no updates for 2 or more of these cycles), we'll start thinking about replacements for that component, and investigate likely alternatives, and bump this item up into the "needs monitoring" risk category - no production impact yet, but as soon as you need to release a patch of that production version using the outdated component, you're gonna be in trouble.
5) Periodically (nightly if you have resources - get something like jenkins or similar for this sort of thing) ensure that you can build these components from source successfully. Especially as they get 'stale,' you'll run into issues - system libs, headers, etc. will change over time, and there will come a point where you are no longer able to build the software without code modification. At that point, if any of your software is still using the version, then you should start raising alarms and bump the risk level up to "severe." This could cripple your production env.
6) If a crisis comes up and a dead project is the culprit... well, we've got the code and can always modify it ourselves, if we haven't found any suitable alternative.
There's really no magic to it - just make sure that developers aren't downloading "every version under the sun," and ensure that the versions you're using are reproducible, available, and actively managed on your end. Risk management is paramount.
Re:Not unique to open source (Score:4, Informative)
Sort of. In practice, taking on an unmaintained library yourself (whether as a public project or just internally) means taking on unknown amounts of technical debt. ("Legacy code" can IMO usefully be approximated to "code dumped on you with unknown technical debt involved".) It might be lovely, it might be a goddamned nightmare.