Posted
by
Soulskill
on Friday April 26, 2013 @04:44PM
from the say-its-name-three-times-in-front-of-a-mirror-site dept.

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?"

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.

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.

A recent review of Github showed that the vast majority of projects had not gone anywhere in quite a while. It is actually rather typical. Same with Sourceforge and the like.

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.

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.

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.

I started with.arc and.zoo. There's always a better compression and damn if another one doesn't becomes popularfor a few years. Then of course you have different operating system so different popular compression schemes; The Amiga was awful in that area.

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.

it is a problem that is unique to open source, but the part that is unique is that it's not a problem in open source.
Because the source is open, "legacy" and "discontinued" software can still be maintained and used by however small a community of users wish to keep it alive. If Windows XP were open source, there would be no pulling the plug on it; there would be a healthy community making security patches for it still.
nothing to see here folks, keep moving.

it is a problem that is unique to open source, but the part that is unique is that it's not a problem in open source. Because the source is open, "legacy" and "discontinued" software can still be maintained and used by however small a community of users wish to keep it alive.

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

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.

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)

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

Personally, I think if they do not respond, then the site should try to contact them - if they still do not respond (after a suitably lengthy time) then it should re-assign you as the new owner.

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.

Some open source projects are in a better state than others, but in my experience it is a good idea to treat all of them as if they can stop working at any time, and manage that risk. In other words, have a contingency plan ready. In some cases you may be able to fx a broken bit of software yourself (or hire a company to do this). In other cases there are alternative software products you can switch to. Or simply accept the fact that whatever it is you've put together will stop working some day (obviously nothing mission critical). The last option may sound scary, especially to managers, but often it's better to have something rather than nothing, even if its for a limited amount of time.

Some open source projects are in a better state than others, but in my experience it is a good idea to treat all of them as if they can stop working at any time, and manage that risk. In other words, have a contingency plan ready. In some cases you may be able to fx a broken bit of software yourself (or hire a company to do this). In other cases there are alternative software products you can switch to. Or simply accept the fact that whatever it is you've put together will stop working some day (obviously n

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

Isn't it the other way around, though? You have the code, and it compiles and runs today. Therefore, that snapshot will always compile and run with the toolset you've got right now. So a "dead" open source project cannot just stop working, but a "live" one easily can, if you keep getting the upgrades and the devs change their minds on how things should be done.

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?

One metric yielding interesting results is the concept of "technical debt", as introduced by Martin Fowler. Sonar Source, for example, measures this metric very well. A project that has seen neither increase ( recently taken risk ) nor decrease ( recent moves toward stabilization ) may very well be dead. I recently used it upon our own software of 580 KSLOC. The interesting conclusion: core stable, some utilities half dead or worse, much life springing up at the functional fringes. This also holds for e.g tomcat. The tactical and strategical conclusions one may draw from such considerations are fascinating.

By measuring regularly, or by having a look at measures done at regular intervals. Have a look at nemo.sonarsource.org [sonarsource.org], all Apache projects are regularly measured there. The graphs are quite telling.

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.

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.

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 forumWhen 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

On a not unrelated note, what's the general view of the current state of Perl 6? I can look at http://planet6.perl.org/ [perl.org] for the view of those close to the project, but what's the word on the street?
I think "word on the street" is a really important metric as to how well a project is doing. Trends are a major determiner of which product potential new users will find. Rather like bank runs: it can be irrational to trigger one but nevertheless rational to follow one.

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?

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

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.

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

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.

Technically, it's not legally possible to put things in the public domain at all, as far as I know. You just have to wait for the copyright to expire. The nearest you can get is something like CC0 (which does disclaim warranties).

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.

Yeah you want to be careful with activity metrics. Awk hasn't seen many updates in the last two years. Mostly because it hasn't NEEDED much in the last ten or twenty years. That means it's already rock solid, not that it should be avoided.

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

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.

The issue about ignoring future proofing is that you can invest a lot of time & effort integrating the tool into your environment, writing scripts etc. If that tool gets obsoleted for any reason, it can be a lot of work to switch to an alternative (this goes for FOSS & commercial software equally). You can get locked in to FOSS just as easily as with commercial, you just have a few more options available with FOSS. Some tools can be swapped in & out at a moment's notice, but if you integrate

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.

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

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?

In 2005, several of us started the Business Readiness Rating project. Its goal was to provide an objective (quantitative) evaluation of free and open source projects largely based on metrics, including project activity, downloads, publications on the project, etc. We originally defined 12 areas for evaluation, which I later reduced to 7. We thought (and still think) that such a tool would be a good idea, but we were an unsuccessful project ourselves, unable to attract sufficient funding or volunteers. The

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.

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

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.

Your assessment of things to consider is a good approach, however adding it all up is a human's work.
BTW You might also want to consider what the OS project is doing to protect its continuity, for example in terms of legal protection, or in lowering thresholds for new developers.

You can perform an analysis using the information of activity in the source code, issue tracker and mailing lists, so you get an idea of the history of the project and how is doing in the last term (who are the most active developers, which parts remain unmaintained, how is the activity of the user/developer mailing lists...).
Some companies/consultants offer this kind of service. For example Bitergia [bitergia.com] license their tools as open source (the MetricsGrimoire [github.com] toolset, among others) so you can extract the met

Contrary to the belief of many managers, sometimes software is just finished. It does what it has to do and adding more functionality is just bloat and changing the UI for change sake results in failures like windows 8. So software that hasn't been updated for some years can just be complete and good as it is.

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 isand what is the trend.

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.