Generic criteria from QSOS version 1.6 Intrinsic durability Maturity less than 3 months if between 3 months and 3 years after 3 years Unstable software with numerous releases or patches generating side effects Stabilized production release existing but old. Difficulties to stabilize developpement releases Stabilized software. Releases provide bug fixes corrections but mainly new functionalities Software knows several problems which can be prohibitive No know major problem or crisis History of good management of crisis situations Software is very likely to be forked in the future Software comes from a fork but has very few chances of being forked in the future Software has very little chance of being forked. It does not come from a fork either Adoption by community and industry Very few users identified Detectable use on Internet Numerous users, numerous references None Few refences, non critical usages Often implemented for critical applications No community or without real activity (forum, mailing list, ...) Existing community with a notable activity Strong community: big activity on forums, numerous contributors and advocates No book about the software Less than 5 books about the software are available More than 5 books about software are available, in several languages Organisation and leadership of developments 1 to 2 individuals involved, not clearly identified Between 2 and 5 independent people More than 5 people Complete dictatorship Enlightened despotism Council of architects with identified leader (e.g: KDE) Activity of the project and around the software Less than 3 developers, not clearly identified Between 4 and 7 developers, or more unidentified developers with important turnover More than 7 developers, very stable team Slow reactivity in forum or on mailing list, or nothing regarding bug fixes in releases note Detectable activity but without process clearly exposed, loing reaction/resolution time Strong reactivity based on roles and tasks assignment No or few new functionalities Evolution of the product driven by the core team or by user's request without any clearly explained process Tool(s) to manage feature requests, strong interaction with roadmap Very weak activity on both production and development releases Activity on production and developmenet releases. Frequent minor releases (bug fixes) Important activity with frequent minor releases (bugs fixes) and planned major releases relating to the roadmap forcast Industrialization level of the project Developments realized at 100% by employees of a single company 60% maximum 20% maximum Services offering No offer of training identified Offer exists but is restricted geographically and to one language or is provided by a single contractor Rich offers provided by several contractors, in serveral languages and split into modules of gradual levels No offer of support except via public forums and mailing lists Offer exists but is provided by a single contractor without strong commitment quality of services Multiple service providers with strong commitment (e.g: guaranteed resolution time) No offer of consulting service Offer exists but is restricted geographically and to one language or is provided by a single contractor Consulting services provided by different contractors in serveral languages No user documentation Documentation exists but shifted in time, is restricted to one language or is poorly detailed Documentation always up to date, translated and possibly adapted to different target readers (end user, sysadmin, manager, ...) Quality assurance process No QA process Identifies QA process but not much formalized and with no tool Automatic testing process included in code's life-cycle with publication of results No bug or feature request management tool Standard tools provided (for instance by a hosting forge) but poorly used Very active use of tools for roles/tasks allocation and progress monitoring Packaging for various operating systems Software can't be installed from source without lot of work Installation from source is limited and depends on very strict conditions (OS, arch, lib, ...) Installation from source is easy The software is not packaged for Debian A Debian package exists but it has important issues or it doesn't have official support The software is packaged in the distribution The software is not packaged for FreeBSD A port exists but it has important issues or it doesn't have official support A official port exists in FreeBSD The software is not packaged for HP-UX A package exists but it has important issues or it doesn't have official support A stable package is provided for HP-UX The software is not packaged for MacOSX A package exists but it has important issues or it doesn't have official support The software is packaged in the distribution The software is not packaged for Mandriva A package exists but it has important issues or it doesn't have official support The software is packaged in the distribution The software is not packaged for NetBSD A port exists but it has important issues or it doesn't have official support A official port exists in NetBSD The software is not packaged for OpenBSD A port exists but it has important issues or it doesn't have official support A official port exists in OpenBSD The software is not packaged for RedHat/Fedora A package exists but it has important issues or it doesn't have official support The software is packaged in the distribution The software is not packaged for Solaris A package exists but it has important issues or it doesn't have official support (e.g: SunFreeware.com ) The software is supported by Sun for Solaris The software is not packaged for SuSE A package exists but it has important issues or it doesn't have official support The software is packaged in the distribution The project can't be installed on Windows A package exists but it is limited or has important issues or just cover some specific Windows release (e.g: Windows2000 and WindowsXP) Windows is full supported and a package is provided Exploitability level Difficult to use, requires an in depth knowledge of the software functionality Austere and very technical ergonomics GUI including help functions and elaborated ergonomics No administrative or monitoring functionalities Existing, functionalities but uncomplete and or need improvement Complete and easy-to-use administration and monitoring functionalities. Possible integration with external tools (e.g: SNMP, syslog, ...) Technical adaptability Monolithic software Presence of hight level modules allowing a first level of software adaptation Modular conception, allowing easy adaptation of the software by selecting or creating modules Everything by hand Recompilation possible but complex without any tools or documentation Recompilation with tools (e.g: make, ANT, ...) and documentation provided Any modification requires code recompilation Architecture designed for static extension but requires recompilation Principle of plugin, architecture designed for dynamic extension without recompilation Project's strategy License Very strict license, like GPL Moderate permissive license located between both extremes (GPL and BSD) dual-licensing depending on the type of user (person, company, ...) or their activities Very permissive like BSD or Apache licenses Very permissive like BSD or Apache licenses Moderate permissive license located between both extremes (GPL and BSD), dual-licensing depending on the type of user (person, company, ...) or their activies Very strict license, like GPL Rights held by a few individuals or entities, making it easier to change the license Rights held by numerous individuals owning the code in a homogeneous way, making relicense very difficult Rights held by a legal entity in whom the community trusts (e.g: FSF or ASF) No pratical way to propose code modification Tools provided to access and modify code (like CVS or SVN) but not really used to develop the software The code modification process is well defined, exposed and respected, based on roles assignment No published roadmap Existing roadmap without planning Versionned roadmap, with planning and measure of delays Software has no sponsor, the core team is not paid Software has an unique sponsor who might determine its strategy Software is sponsored by industry No detectable strategy or strong dependency on one unique actor(person, company,sponsor) Strategical vision shared with several other free and open source projects but without strong commitment from copyrights owners Strong independence of the code team, legal entity holding rights, strong involvement in the standardization process