A component is a free and open source software (FOSS) project which is selected to be part of the Tiki Suite. While it's subjective to pick a component, here are some general guidelines that are thought to be a good fit with Tiki. For general info on how Tiki works, please see Tiki Model. If you have some ideas, please do share them.

The premiere place to evaluate and compare FOSS projects is Ohloh.net. Other great sources include

• AlternativeTo
• Social Source Commons

Fits the use case

As described at Tiki Suite use cases

Multi-functional

As we want to reduce the number (complexity) of interaction between components, it's best that they are handled within each app. So "suite mentality" is preferred. Having all the desired sub-functionality which complements the other elements of the Tiki Suite is of course important. However, this is a long term project and if a feature is missing, we can just add later on as we complete the puzzle.

Free and open source software (FOSS)

This should be obvious but just to be sure! Preferred license is LGPL v2 because that is what Tiki uses.

Activity level

Number of commits and number of contributors will be evaluated on Ohloh.net

Longevity

Tiki Suite is a long-term projects and many many organizations will depend on it. Thus, a project should ideally already have a history.

Leadership

Projects with good leadership and good community vibe. No one wants to be stuck in a non-fun place!

Community

Projects with larger/vibrant communities have more to gain from and more to contribute to Tiki Suite. And the diversity of the community is a definite strength. Diversity leads to different ways to approach a challenge and improves the solution.

Roadmap and frequent releases

Where is the project headed? What is the plan/vision?

Tiki has a major release every 6 months, which has all kinds of benefits. Ideally, the project has scheduled releases so we can have a good cadence.

Ease of use

Ideally, people can use with little or no training and documentation is available. If the features are there but are not easy enough to use, this is something that we can improve together.

Interoperability

There should be a commitment to being as interoperable as reasonably possible to projects outside the Tiki Suite, by using (and enhancing if need be) open standards and protocols.

Multiplatform

Especially client side, we have to assume organizations will have eclectic hardware, including mobile devices.

Open development model

The project must be open to contributions. Project should be happy to add these new features ideally, in the core of the official next release and not a 3rd party add-on that needs to be maintained separately.

If a project has a non FOSS component, it could be reticent to accept the inclusion of a feature which is an alternative. Please see: Open Core debate.

Being backed or managed by a foundation/association is preferred. Vendor lock-in is to be avoided.

Chat/Forums/Mailing List/Bug Tracker/Source Repository/Wiki

Projects should have an online presence, where it's easy for new users to ask questions, get support, join the community, etc.

• Source code should be readily available via SVN, Git, etc.
• An IRC chat room or similar should exist, with regular presence of key people
• Documentation and planning should be done with open proceses, and tools like a bug tracker, mailing list/forums and wiki.

Available as a SAAS

We expect that a good number of future users will enjoy the flexibility and avoidance vendor lock-in. Yet, they still want to hire someone else to host and maintain it. Encouraging SAAS is part of the project.

Availability of a services ecosystem

Similar to SAAS, future users will want to be able to hire Tiki Suite expertise for support, training, customizations, feature development, etc. Encouraging this is an inherent part of the project.

Technology

Should be based on sufficiently popular technology so it has long-term viability. However, it doesn't have to be the most popular. PHP / MySQL / Smarty / jQuery / Zend Framework is preferred because it's the technology Tiki uses. However, it's clear that we'll need some other technologies that are better suited (ex.: to desktop apps)

Multilingual

Should have (or be ready to add) a process to collaborate on translations.

Willingness to participate to the Tiki Suite

The project should be willing to promote the Tiki Suite to its community (ex.: with a page explaining the project and an announcement). Ideally, each project of the suite will Dogfood at least part of it. Realistically, migrating existing data is not easy, but for new needs/projects... Project should be eager to increase interoperability with other components.

A Good FOSS Citizen

Upstreaming fixes, discouraging license proliferation, etc.

Active in FOSS events

Such as FOSDEM, OSCON, FISL, RMLL, etc.

The Open-By-Rule Benchmark

http://webmink.com/essays/open-by-rule/
http://blogs.oracle.com/webmink/entry/a_software_freedom_scorecard

Also see the SWOT analysis for Tiki: http://tiki.org/SWOT

QSOS

QSOS is a method conceived to qualify, select and compare free and open source software in an objective, traceable and argued way
http://www.qsos.org/?page_id=3

Coolness

Some projects just have a little something special which makes you want to be part of it 😊

Related links

• http://osswatch.jiscinvolve.org/wp/2013/05/08/4-tips-for-keeping-on-top-of-project-dependencies/