Concept: Trustworthy elements
A trustworthy element is as a specific factor or aspect of the software development process, or of product results that indirectly influence the perception of the trustworthiness of the FLOSS development process. Two different scenarios were considered when identifying the trustworthy elements: software integrators and development communities.
Relationships
Related Elements
Main Description

Trust is correlated with the quality of a software product and it is to some extent influenced also by subjective perceiving of the quality of trustworthiness of a software product. A trustworthy element (TWE) can be seen as an approach to solving one or several commonly occurring problems on FLOSS development process. TWE can be specific to FLOSS developement process or can be inspired on CMMI practices.

In addition to CMMI levels 2 and 3 practices, OMM is based on twelve trustworthiness elements:

1. Product Documentation (PDOC) – Potential integrators of FLOSS products want the product documentation to be exhaustive and easy to understand. A good documentation may also facilitate community involvement, as people would know how they can contribute. By product documentation they refer to: Product design / architecture documented (developer documentation), User documentation, and Technical documentation (for troubleshooting). Documentation must be up to date because unskilled users may encounter serious problems if the documentation is not appropriate for a specific version of the product and therefore they can stop using the FLOSS product;

2. Popularity of the SW Product (REP) – The more popular the software product is the more likely people will trust on it. Such popularity can be indicated by, for instance, the number of users that have downloaded the product and that are using it. Discussions in mailing lists, forums, bug reporting systems and other communication environments are also relevant to indicate the popularity of a FLOSS product;

3. Use of Established and Widespread Standards (STD) – Standards used are relevant for the FLOSS product. FLOSS developer communities tend to value open product standards such as http, WSDL, SOAP and process standards such as RUP. It is only natural that FLOSS integrators are positively inclined towards well established standards, which is correlated with product quality;

4. Availability and Use of a (product) Roadmap (RDMP) – the appearance of this element is directly related to the relevance FLOSS communities and surveyed companies attribute to process in the FLOSS context. Important aspects are, among others: responsibility for the roadmap is defined, roadmap includes plans for at least the next 2 versions, and roadmap is regularly updated. The availability and the use of a roadmap is an important trust element. It provides an insight not only in the development process followed in the past but it also describes the improvements that are planned for the near future. The roadmap must be detailed enough and it has to be respected in order to ascertain a high quality level of the development process;

5. Quality of Test Plan (QTP) – Testing software appears as a relevant activity to increase the trust in a FLOSS product, particularly the quality of test plan. This includes not only the schedule for test but also planning required resources, the order in which tests will be carried out, tools to be used, test  environment, testing responsibilities, how test results will be analyzed, defects corrected and open issues handled. Testing is an important part of classic software development and is often underestimated in the FLOSS process. Successful FLOSS processes and communities however conduct extensive tests on their products;

6. Relationship between Stakeholders (Users, Developers etc) (STK) - This trustworthy element refers more to the quality and degree of collaboration between developer communities and users than to formal sharing of responsibilities between stakeholders. It is important to know if there is good collaboration within the groups and how they communicate;

7. Licenses (LCS) – This trustworthy element refers to the ability of a FLOSS product to selecting and managing license properly. For instance, it is important that the product does not contain any commercial components. The decision about which license will be used is a critical decision that has to be taken in the beginning of the FLOSS development process. Licenses are even more important for companies that would like to integrate the FLOSS product with other their products;

8. Technical Environment (Tools, OS, Programming Language, Dev Environment.) (ENV)
Tools, operating systems, programming languages and environments used by the FLOSS products developers are important factors influencing the trust surveyed companies have in the FLOSS process.  Probably these elements have one of the most important impacts specifically on the development process. Before adopting an FLOSS product, integrators would like to know details of operating systems, tools, languages and environment in order to check if the technical environment of a FLOSS product is compatible with integrator needs;

9. Number of Commits and Bug Reports (DFCT) – The number of commits and the number of bug reports are also considered important for the evaluation of the FLOSS process. They are indicators of FLOSS product popularity. It also may indicate that the product is being actively developed and supported, and that further change requests and bug reports will be undertaken;

10. Maintainability and Stability (MST) – A potential integrator is more likely to view a FLOSS product favorably if it is proven to be maintainable and stable;

11. Contribution to FLOSS Product from SW Companies (CONT) – For a potential integrator, participation of reputed software or IT companies in the FLOSS development may be a positive indication of the FLOSS product. It may serve as a sign of quality for the FLOSS product; and

12. Results of Assessment of the Product by 3rd Party Companies (RASM) – Assessment of the product by 3rd party companies may count in favor of the product, when potential integrators evaluate FLOSS products for use in their own development.