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: (Score:1)
Seems to me the metrics are simple: 5 years since the last revision, nothing replaced its function, and it was irreplaceable.
Well, to an extent that's true (except hopefully for the irreplaceable part). What I don't see is any functional difference between open-source and commercial software. I have seen plenty of abandoned closed-source projects, and these might be even more frustrating if the user has actually paid money to use them.
Yes... (Score:4, Interesting)
sourceforge, github, and other major OSI project hosts feature both last updated dates and when a project is discontinued often times notices stating so. Ultimately, some responsibility is placed on the author(s) & maybe even the community for managing this. Search engine rankings take care of the rest. And of course, there is no way to bat 100% here, some will be missed with this and just about any other method.
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.
Re: (Score:3)
When you introduce commercial aspects to OS, it becomes a completely different beast because now you've promised deliverables for the money. The person selling at that point is legally obligated to deliver what they're promising, so if a project goes stale and doesn't work with future technologies, but is still advertised as so in a deceptive manner, they either have to take them down or face a barrage of FTC complaints leading to legal action.
Re: (Score:2)
"When you introduce commercial aspects to OS, it becomes a completely different beast"
That was my point. If they want regular, professionally-provided support, they won't get it for most Free-and-Open-Source products. They should probably opt for commercial instead.
Check the community (Score:4, Insightful)
Try and find someone looking for help using it online. See what people say to them. If there are lots of recent problems and responses that don't seem to suggest using other products, its likely in a good state to use.
If no one is looking for help using the library, its either not in use, or way too easy to use (has that ever happened?).
One thing to look out for is that if something works well, it might not need updates very often (or at all, depending on what it is). Don't abandon something simply because its old, or not being updated. Now, it its not being updated, has lots of open issues, and no users, thats a problem.
You can also look for some issues/tickets, and see the response times on them.
Re: (Score:2)
I started with .arc and .zoo. There's always a better compression and damn if another one doesn't becomes popular
for a few years. Then of course you have different operating system so different popular compression schemes; The Amiga was awful in that area.
Why can't we all just get along (Zip).
Re: (Score:2)
Take zlib for example. Very little update in years. Yet its perfectly feasable that we could have a compressor that does 5% better (see 7z, kzip, etc). Yet everyone uses it.
AFAIK zlib is still the best if you measure the speed/compression ratio.
Re: (Score:2)
AFAIK zlib is still the best if you measure the speed/compression ratio.
That's a good reason to like zlib.
But technically the best way to get speed over compression is no compression at all (infinitely fast / 1).
Technically. [runs to hide from ballistic fruit]
Re: (Score:3)
AFAIK zlib is still the best if you measure the speed/compression ratio.
But technically the best way to get speed over compression is no compression at all (infinitely fast / 1).
No, because you also have to consider disk I/O time, and CPU time is relatively cheap, so on-the-fly compression is faster than no compression for many types of data.
Re: (Score:2)
Indeed. My boot image (initrd) is xz compressed. If I use no compression, it takes longer to boot since it need more HDD read time, and decompressing is faster.
Re: (Score:2)
No, Chii. That's just source code.
Not unique to open source (Score:5, Insightful)
This isn't a problem that is unique to open source. Several commercial libraries that we have used in the past have entered the twilight zone where the developer is neglecting them, and refuses to release any sort of roadmap or EOL announcement. Eventually, you just have to make your own call based on how much work it will be to move to a new library vs the risk of staying with the current one. At least with open source if you get stuck with a dead library you can choose to take over maintaining it on your own either as a long term strategy or a short-term stop-gap until you can move onto something else.
Re:Not unique to open source (Score:5, Insightful)
Re: (Score:2)
This is not necessarily true. Poor documentation seems to be the norm for the smaller (and some larger) FOSS projects hosted on Sourceforge and Github. If the project is dead (as in no activity) don't expect to be able to dust it off an
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.
Re: (Score:3)
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.
Is your hypothetical nightmare worse than the nightmares created by the choices you have with an abandoned closed library? It pretty much boils down to:
a). Doing nothing and living with a buggy closed library you can't fix at all, at unknown cost, placing your business at risk?
b). Being forced to migrate entirely to a new library with all the "technical debt" that entails, at unknown cost, placing your business at risk?
Those are just about the only two choices with a closed source library (aka binary blob)
Abandoned project takeover (Score:3, Interesting)
of course, if you're using it and you have the source code, then its not dead - except the old project page might no longer point to the currently updated project site (ie your fork).
All the FOSS sites need a 'takeover' policy for dead projects that is more than just fork [sourceforge.net]. That link says to contact the abandoned project admin and ask to be added to the project to continue it, and if they do not respond, create a new project site with the old code. Personally, I think if they do not respond, then the site sh
Re:Abandoned project takeover (Score:5, Insightful)
The length of time to wait is much longer than you want. The original author of the project still owns the copyright and the rights to the name of the project. The best option is to fork the project and start fresh.
Risk management (Score:3, Insightful)
Re: (Score:2)
Re: (Score:2)
Software isn't going to simply stop working...
At a worst case, the software is going to inhibit your ability to upgrade other pieces of software that it depends on, eg you may have to continue running an old OS to go with your old application because the old application won't run on new OS versions.
This can become a problem if there are unfixed security holes in either the application, or other things it depends on.
That said, software becoming abandoned by its creators is certainly not unique to OSS. Commer
Re: (Score:1)
Software isn't going to simply stop working..
Unless it's using DRM ;)
Re: (Score:3)
Yes, good point, although OSS is unlikely to ever use anything like that, and if it does you could remove it - so another benefit of using OSS.
Re: (Score:3)
But the gist of what you're saying is very sensible. If you are deprived of a vital resource tomorrow, how will you deal with that contingency?
Technical debt (Score:5, Interesting)
Re: (Score:2)
If you're a user of an open source project, how do you tell if the technical debt is increasing or decreasing?
Re: (Score:2)
Developer List (Score:4, Insightful)
The first thing I do with regard to investigating any OSS is to find their developer list and skim the last few months of it. It's a good way to see the level of activity, responsiveness, and how cohesive or combative the core is.
Stackoverflow (Score:4, Interesting)
Another good technique is to search Stackoverflow [stackoverflow.com] for questions about the project you are considering. Look at both the number of questions asked and the quality of the answers. Especially look for questions like "Should I be using XYZ?" and "XYZ vs {Alternative to XYZ}".
Stackoverflow is moderated somewhat like Slashdot, so the best answers will usually bubble to the top.
Re:Stackoverflow (Score:4, Insightful)
Re: (Score:1)
Such questions are often closed on Stackoverflow because they're about opinion not technical issues.
Re: (Score:2)
Very good point.
Also I'll look at
-the last few months of commit logs--how many contributors, patch series, recurring contributors...
If you don't have a repo and browser, that's a bad start. If it's tarballs only, I'd better know that it's something interesting.
And if you do something non-predictable like archives on mediafire, good luck.
-the community mailing list archive or forum
When that's empty, it's a bad sign unless you can tell that the project is used elsewhere. Spam there is a VERY bad sign.
-popco
Perl 6 (Score:1)
The market for genuine routine maintenance (Score:3)
Most really usefull software needs maintenance, or at least reviews to verify none is needed, on a routine basis. This is usually dull, thankless work. In business, it is often done by old codgers (like me before i retired) that are well paid for very little actual work. It is a vital function, that was supposed to have been covered in open source by users paying for the service.
In many cases this seems to have worked out well with large organizations footing the bill. iBM, HP, AT&T etc, have staff people who kept the components they need working. Their priorities aren't yours.
Do we need a system for keeping codgers comfortable and personal use software working?
Unpleasant Trend (Score:2, Interesting)
I've had a couple of cases where I needed a feature, that there had been lots of requests for, in existing software whose development had slowed or stopped. I offered to hire the developer, bounty style, but they weren't interested.
I hired professional programmers to add the feature or make necessary changes to the existing code. I then submitted the code as patches to the original developer, hoping that he would accept the patches and make it so I didn't have to patch and compile everytime there was an upd
Re:Unpleasant Trend (Score:4, Insightful)
I've had a couple of cases where I needed a feature, that there had been lots of requests for, in existing software whose development had slowed or stopped. I offered to hire the developer, bounty style, but they weren't interested.
I hired professional programmers to add the feature or make necessary changes to the existing code. I then submitted the code as patches to the original developer, hoping that he would accept the patches and make it so I didn't have to patch and compile everytime there was an update or distro change. My patches were always GPL and there were no restrictions on them, so if the developer didn't like the style or specific implementation, they could use my patch as a starting point or model and change whatever they chose.
In all cases, the developers have not incorporated the patch. In most cases, they have done nothing at all. I'd likely have been better off just buying Windows COTS.
Have their been any updates at all since you submitted your patch? If not and the time period is long enough to believe there never will be, then your best course of action is to fork. As one with enough vested in the project to pay for further development, you are probably in a better position to steward the project than the original developers, who likely have no more use for the program.
If there have been updates, then you have a more sticky position. Most likely, the maintainers considered your patches to be too narrowly applicable at least relative the difficulty required to integrate and maintain them. At that point, you are pretty much stuck re-integrating your patches with each release.
Windows COTS wouldn't necessarily solve your problem either. It just takes away the option to patch your own. If the company is not interested in making the changes you request, there isn't much you can do about it. The exception would be of the commercial software is more popular and better maintained but that's true in the open source world too. If you have a choice between two projects, both of which an do the job with adjustments, you are most likely better off contributing the one that is actively maintained than the one that isn't, even if the required changes are more extensive.
Re: (Score:3, Interesting)
I mean no disrespect to someone with a UUID that is low enough to... have done many things.
But I've been in some FOSS projects (small ones) -- and there's a lot of...issues I've seen with submitters you didn't cover. I guess the OP should get it...but I figure since you're the person explaining things...
1) Being a FOSS dev, you may still be commercially paid and have a noncompete in place.
2) The project you're on may not be GPL. Thanks for submitting stuff with an incompatible license I can't absorb. Ev
Re: (Score:2)
2) The project you're on may not be GPL. Thanks for submitting stuff with an incompatible license I can't absorb. Even if you said no restrictions, if you put GPL on it, I'm now SOL and have a god-awful license tracking nightmare. Thanks for nothing. Please resend with "public domain" and a signature.
Technically, it's not legally possible to both put something in the public domain and disclaim warranties and fitness. The closes you can come to covering your ass and making it as public domain as possible is a two clause BSD license, because otherwise if some idiot uses it in a life support system or other critical system, it's your ass, and your house, and your car, and your future earnings on the line if things go wrong and theres no disclaimer.
If there were a specific hold harmless clause in Federal l
Re: (Score:1)
Re: (Score:2)
What about finished projects? (Score:3)
Sometimes, a program can be dead because it's obsolete. Others can appear dead because they have simply been completed.
For example, I'd guess that xclock hasn't been updated in many years... but it's still widely used for testing X11.
Indeed. Are awk, sed, grep, vim dead? (Score:5, Insightful)
Re: (Score:3)
awk != gawk. the one true awk is maintained by bwk.
and likely has seen very few updates. it is rock solid
Actually Apple sent a number of patched back to the one true awk to pass UNIX conformance testing by The Open Group, and sent those chnages back to bwk.
Sources are here: http://opensource.apple.com/source/awk/awk-18/ [apple.com]
Not understanding open source (Score:2)
I'm going to suggest that while there are larger open source consortiums like Apache that organize developers and projects such that they do wind up looking like a commercial project, you need to remember the main difference:
YOU are responsible for open source software implementations. There is no inherent support structure, there is no liability nor responsibility to maintain, fix, or continue development on an open source project. If you want to implement it, you are either paying for developer time (per
By Reading the Source Code (Score:2)
Starflight 3 (Score:2)
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: (Score:1)
Nice set of practices.
Re: (Score:2)
You can maintain it yourself (Score:3)
An important difference with open source is that, if a component you rely on is abandoned, you have the choice of maintaining it yourself. I'm not suggesting you want to take over development of large projects, but in some cases this is a real option. It's especially relevant to the last category mentioned in the post: "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." If you're using a library that's stable and does what you want, and your only concern is keeping it working when other things change in the future, that may be quite easy to do yourself.
Re: (Score:1)
Good comment until you started talking about life cycles.
"Life cycles" are an issue in some (read numerous) circumstances.
More or less, it's a question of how much of #2 you need to do yourself. And you know that supporting LibreOffice yourself is probably not an option, but avoiding an office suite is also a bad idea.
Scenarios:
1) You need to provide a device that's supported for the next 3 years. Upstream has high churn.
If there's a regularly-updated stable branch/other support policy, you can just use t
inactive IS NOT the same as "not useful" (Score:4, Insightful)
the typical example that i give here is "python htmltmpl". htmltmpl was written to solve a very specific problem: minimalist templating of HTML by allowing dictionaries of key-value pairs to substitute into HTML (value text replaces the key when named) and to do likewise for lists of dictionaries in order to e.g. create tables.
very very simple.
the problem is this: the actual scope of the work required means that the actual programming required was extremely straightforward. i.e. it was done, completed - problem solved. the scope of the work required is clear; the scope of the work required does not change; the scope of the work required does not *NEED* to change.
therein lies the problem, namely that the fact that python-htmltmpl has quotes not had any development quotes means that, as far as sourceforge is concerned, the project is "dead". look at the release dates - 2001 for god's sake!
http://htmltmpl.sourceforge.net/ [sourceforge.net]
the point is: just because a project hasn't had any development done on it, that DOES NOT automatically mean that it doesn't do the job. correlation != causation. python-htmltmpl *clearly* does the job it's intended to do.
i mention this case specifically because i have seen a large number of HTML "templating" languages come and go. the php-inspired one which used syntax. zope with the dreadful and insane embedding of python in templates and templates in python. many many more, all of which caused me to despair when i saw them, so much so that i was inspired to talk at one UKUUG conference at some length about best practices of keeping programming languages declarative i.e. *never* embedding programming languages into HTML (even if it's php).
and once you follow the sanity-restoring rule of keeping a programming language declarative (e.g. in the php case beginning the file with as the last two characters and AT NO POINT EVER NOT FOR ANY REASON WHATSOEVER FALLING BACK TO OR PERMITTING STATIC HTML TO BE OUTPUT IMPLICITLY)... ... once you follow that rule, then you find that you need a templating system such as php-htmltmpl or any of the others that exist. and, once you've looked closely at what you actually need out of an HTML templating language, then actually, htmltmpl provides a *really* good very simple system which covers pretty much everything you'll need. need to do an expression which is a mixture of variables and HTML? generate it explicitly in php, put it into the array - don't for god's sake try to use a god-awful mix of print, echo, dots and christ knows what else. just.. don't.
so i'm putting this out there because in certain cases, what you find is that the code that you need appears "dead", but that's not actually the case: the failure of sourceforget and github by their "metrics" have relegated perfectly good and *completed* code to obscurity.
you are therefore encouraged to participate in *unfinished* projects, with their constant changes, moving targets and massive contributions which may or may not be correctly managed, because it is those projects that have "99% activity". does that sound like a good thing to you?
Easy test! (Score:2)
BRR Project - tried building FOSS eval tools (Score:2)
Re: (Score:1)
Our university was in a similar situation than the poster; we had a big project to realize and the choice between proven, commercial software, or an open-source one. We quickly realized that using subjective review was not an option to compare them. Fortunately there are objectives ways to measure open source projects, with metrics like maturity, vitality of the community, quality of code, probability that the project will go out of fashion, etc.
We used the QSOS (Qualification and Selection of Open Source S
Open source software never dies (Score:2)
There is a big difference between commercial and open source when it comes to life status : you can always throw time or money to resurrect an inactive open source project. Open source software never dies, it just goes idle, and is always available for whoever wants to adopt it
Kernel Impedance? (Score:2)
Thinking out loud here - some sort of probabilistic metric based on distance measured in time or number of patches / release cycles of the underlying kernel since the last project maintenance? I.e. the probability that 1 kernel patch will break a piece of software unless maintained is x; I'd expect that x rises by some non-linear function with the number of patches.
Beware of Excel Management (Score:1)
Code, Issue tracker, mailing lists analysis (Score:1)
Finished software exists (Score:2)
I look it up on www.ohloh.net (Score:2)
which is an excellent site which give metrics on open source projects number of developers,
lines of code progression over time and many more useful graphs and metrics to help assess how active an open source software is
and what is the trend.
Re: (Score:1)
Slashdot: could we please have a "-" next to each article title bar that we can check to collapse the article?
Re: (Score:2, Flamebait)
Re: (Score:2)
I just hope he's mad enough to file suit. Groklaw/Popehat/NYCL's writeup of APK having his ass handed to him by a judge will be hilarious.
Re: (Score:1)
Re: (Score:2)
Is that really spamming? I don't think so. And I don't even think he's trolling. The most reasonable assessment I've seen is that he's off his meds. OTOH, if there actually were a lawsuit, perhaps he should mention what court it's in front of (near the top, as I don't read much of his posting). If there were reliable information that one could judge on, it might be reasonable to alter my opinion.
Re: (Score:1)
apk is my favorite slashdot troll.
Re: (Score:2)
Ballmer, you're a really naughty boy.
Hey, free donuts down in the lobby!
[aside] that might shut him up for a while [/]