Loading...
 
Skip to main content

History: Tiki Suite FAQ

Preview of version: 43

What is Tiki Suite?

A suite of Free and open source software collaboration, productivity & publishing tools for small & medium-sized organizations, featuring Email + Wiki + CMS + Groupware + Commerce + Accounting + Document Management + CRM + Web conferencing + Telephony + Instant messaging + Video management + E-learning, etc.

Who is the target audience/use case?

At first, we'll focus on SMEs. Once SMEs are well covered the second use case will likely be Web agencies. The difference being they don't need firewalls, LDAP server, but easier hosting reselling, etc.

Please see: Tiki Suite use cases

Who is behind this?

This is an initiative of members of the Tiki community. See Tiki Suite People.

What are the components?

This is currently being decided. See Tiki Suite Components. Please share your thoughts!

How are the components selected?

See Tiki Suite Component criteria. If you have some ideas, please do share them.

Will the components change?

A little as possible and as often as needed. Changing a component involves learning new things, testing, etc. so it is not desired. However, if a component has a major problem (ex.: becoming inactive), we'll deal with the situation. The Tiki Suite Component criteria minimizes the risk of this happening.

Where is the code?

Tiki Suite will host as little code as possible and as much as needed. Hopefully, Tiki Suite will host no code because everything needed will be incorporated into the various components. However, it will be a Tiki configuration profile, documentation and community support site (forums, bug tracker, chat etc)

Where do I request a feature or report a bug?

In general:

If it's specific to a component, it should be reported on the relevant place for that component. For example, in Tiki, we have a wish list at dev.tiki.org

If it's related to interoperability between components, it should be discussed on the Tiki Suite site and links to this discussion should appear on the components involved.

Do I have to use everything in the Suite?

No. Don't install/activate what you don't need.

Can I replace part of the Suite?

Yes, it's all Free and open source (FOSS). You can use different components which suits you better (legacy data, better features, etc.) Please do share why/how you did this so other can learn and make better choices for their projects.

Will there be overlap of functionality throughout components?

Yes, that is inevitable as each component is an autonomous package which offers lots of features. Please see: component feature overlap. Just use the component best for you.

Isn't this just too complex to be possible?

Tiki has a great track record for coping with complexity. (see section about Tiki Suite)

Will I be locked in?

No. Projects in the Tiki Suite commit to working together for better interoperability (within the Suite, but also beyond). The Suite recommends projects which are known to work well together but you can add any component you like.

Can I get it via SaaS?

Many of the apps have readily available Software as a service (SaaS) options. This is encouraged for all components. And we hope some SaaS offerings will emerge for the whole Suite (could be a package).

More details at: http://tiki.org/Business+Models#Advanced_hosting

Will it be available as an appliance?

At first, Tiki Suite will essentially be a recipe of how to configure various components known/tested/committed to woking well together. But later, it will perhaps be distributed as an image (ex.: vmware, VirtualBox, or .iso file from a Live CD).

What is release schedule?

Most projects have a "release when it's ready" approach so it's hard to coordinate with others. It's also a challenge because it's a mix of server components like ClearOS (3 year cycle) to Web apps like Tiki (6 months cycle) and some desktop apps which can have an even faster release cycle.

Since Tiki is the component which will have the most interactions (and thus the most complexity), and it already has dealt with version dependency interactions with BigBlueButton and Kaltura for several versions now, the plan (until someone proposes something better) is to follow Tiki's 6-month release schedule.

So whatever is the latest stable version at the time of the Tiki release becomes the corresponding supported version. We'll work the details out with the various projects .

For example:

Tiki 8 (October 2011) 9 (April 2012) 10 (October 2012)
BigBlueButton 0.71a .8 .81
Kaltura 4 4 5
Piwik 1.6 1.8 2.0
ClearOS 5.2 6.2 6.3
ejabberd 2.1.10 2.1.14 2.2.1
blue.box 1.03 1.06 1.51


We'll encourage all projects to move to a Time-Based Release Schedule and we can then all move to Syncronized releases.

Later on, when things are stabilized and community is large enough, we'll look into adding an LTS version (like Tiki has).

Do any other similar projects exist?

Please see: Tiki Suite alternatives

Since very few such projects exist, maybe it's just a bad idea?

Time will tell. However, the people behind the project think that this will be very successful.

The Tiki community has an extensive user base and has (over the life of the project) had over 950 000 downloads. And each component has a community as well.

Will other similar projects emerge?

We expect and hope so. This will permit to learn from each other, improve interoperability in general and very likely share code.

Why select client-side apps as well as server-side?

The goal of the Tiki Suite is to have a global solution, and that includes client-side technology. Tight integration and stability is easier to attain when you can influence both client & server. This will permit us to implement or improve standards and protocols.

Will Tiki Suite components be able to interact in exclusive ways?

That may happen as we develop better interoperability, but we'll use open standards and protocols so it is reproducible.

What is the benefit for current users of components?

Each community will get significant visibility. This will lead to growth with users from the other communities. It will permit to have streamlined access to complementary functionality.

Is Tiki changing course of its all-in-one model?

Tiki's strength is its integrated feature set and community development model. Please the Tiki model for background information.

Tiki is not removing any functionality and will continue to grow and add more as it always has. It has been the FOSS Web Application with the most built-in features for a while now. This will remain the case unless other FOSS projects change their model or grow much faster than Tiki.

Features that can be done on shared hosting, with the underlying technology (PHP/MySQL/jQuery/Smarty/Zend Framework) will continue to be added. This being said, there are things that you just can't do on shared hosting, and Tiki community members need a solution. Tiki Suite will extend that solution.

So this is not changing course, this is extending the Tiki Model beyond the boundaries of Tiki code 😊

What is the license?

It depends on the license of the components. Presumably, the Suite would be LGPL (like Tiki) and for the AGPL parts, there would be documentation on how to activate but this will be discussed/decided by the active participants. It will for sure be an OSI approved license

How can I join the project

Add yourself to the list of People

To participate, simply create an account on tiki.org and start participating. This site is a wiki. If you need/prefer to contact someone in private, please write to marclaporte at this domain name.

History

Information Version
Marc Laporte 64
View
luciash d' being 🧙 Mass search and replace 63
View
Marc Laporte Moved to WikiSuite.org/FAQ 62
View
Marc Laporte Openfire Meetings is both for XMPP clients and WebRTC 61
View
Marc Laporte 60
View
Marc Laporte Better answer and cleanup 59
View
Marc Laporte 58
View
Marc Laporte 57
View
Marc Laporte Tiki doesn't like -- in hyperlinks 56
View
Marc Laporte 55
View
Marc Laporte 54
View
Marc Laporte 53
View
Marc Laporte 52
View
Marc Laporte FOSS -> FLOSS 51
View
Marc Laporte 50
View
Marc Laporte 49
View
Marc Laporte Removing names of components that are not currently selected 48
View
Marc Laporte 47
View
Marc Laporte 46
View
Marc Laporte 45
View
Marc Laporte 44
View
Marc Laporte 43
View
Marc Laporte 42
View
Marc Laporte 41
View
Marc Laporte 40
View