- What is Tiki Suite?
- Who is the target audience/use case?
- Who is behind this?
- What are the components?
- Will the components change?
- Where is the code?
- Where do I request a feature or report a bug?
- Will there be overlap of functionality throughout components?
- Isn't this just too complex to be possible?
- Will I be locked in?
- Can I get it via SaaS?
- Will it be available as an appliance?
- What are your thoughts with respect to offline?
- What is release schedule?
- Do any other similar projects exist?
- Since very few such projects exist, maybe it's just a bad idea?
- Will other similar projects emerge?
- Why select client-side apps as well as server-side?
- Will Tiki Suite components be able to interact in exclusive ways?
- What is the benefit for current users of components?
- Is Tiki changing course of its all-in-one model?
- How can I join the project
What is Tiki Suite?
Tiki Suite is a selection of Free / Libre / Open Source Software (FLOSS) server, web, mobile and desktop apps with a concerted focus on greater interoperability, security and adaptability, which is aimed at small & medium-sized organizations.
The Tiki Suite is especially suited to decentralized and knowledge-centric organizations and offers most (80%+) of the features all organizations need, such as: Email, Website & Blog, Shopping Cart, Intranet & Project Management, E-learning, Social Networking, Knowledge base, File sharing, Issue Tracker, Video-conferencing, LDAP, VPN, Gateway, Network, etc.
You can install anywhere (home, office, laptop, data center, 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!
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 (upstreamed!) 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?
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.
Will there be overlap of functionality throughout components?
Yes, that is inevitable as each component is an autonomous package which offers lots of features. 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: https://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 be more automated.
What are your thoughts with respect to offline?
We are more & more moving to an always online mode. 3G access is ubiquitous and cost-efficient. Cities like Montréal are installing in the metro. Let's also take advantage of HTML5 Offline. This being said, offline email, contacts, calendar are available via ActiveSync in Kolab.
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 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 .
|Tiki||8 (October 2011)||9 (April 2012)||10 (October 2012)|
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?
It's mostly that it is a huge amount of work, and since Tiki Suite is so open, it makes sense to join forces.
The Tiki community has an extensive user base and has (over the life of the project) had over 1 000 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 FLOSS Web Application with the most built-in features for a while now. This will remain the case unless other FLOSS 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 / Bootstrap) 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
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.