Slashdot Mirror
Ask Slashdot: How Do You Assess the Status of an Open Source Project?
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?"
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.
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.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Another good technique is to search Stackoverflow 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.
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. 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.
3) Many times I've received patches 'in the wrong place' in the stack. Things requiring changes that should be submitted to another library and were mangled as a fix in my platform.
4) Poor fit. Wrong option, rare case, you changed lots of whitespace becuse you don't know how to use your editor. Wrong style guide, you name it.
5) Bugfix submitted without test case.
Now admittedly, I'd always reply and let people know how to fix thse. But depending on the problems...I've seen cases where it wouldn't have been worth it.
Lastly, the hard one -- sometimes peoples fixes are just in the wrong spot and paradigm. They're written in an OO message-passing philosophy in something using a reactor/worker queue. It's not /just/ that it's work to integrate and maintain it, it's that the solution is just 'wrong for us' and the problem it fixes is not a priority. That's a really big risk if you pick up joe-random-developer that knows a language but not a platform.
FOSS is and should be inclusive, but sometimes the submitter has to ask a few questions to fit into the software.
The OP indicates they hired professional programmers, but they did not say what they hired them /for/. If you hire me to 'fix a bug in a program', you're getting a very different fix than if you hire me to 'submit a bugfix for reintegration into mainline' or to 'write a plugin doing X for application Y'
In both cases I'll ask about the quality of work you expect, what you believe is a fair price, and check what you intend to do with it. However, if like many small businesses you just want it done fast and working -- the software may very appropriately /not/ be up to standards. It's their right as a hiring manager to choose.
More relevantly in the context of a freelancer, it's my professional pride and reputation at stake to choose my implementation in the absence of terms to the contrary.
If you're clearly a penny pincher and want fast results, I will place in comments that it's a quick and dirty hack, and give you your four hour turn around with advice and a quote for a proper and full fix. And the maintainers would have every right to say 'fuck that submission'.