As of 2022-03-06, the last significant update to this page was in 2012 or so, and thus, many things have changed and it deserves a major review. Any volunteers?
SWOT Analysis is a strategic planning method used to evaluate the Strengths, Weaknesses, Opportunities, and Threats involved in a project or in a business venture. It involves specifying the objective of the business venture or project and identifying the internal and external factors that are favorable and unfavorable to achieving that objective. Source: SWOT analysis on Wikipedia
As a PHP/MySQL app, Tiki is already very easy and inexpensive to host, and available through all the major 1-click installers. The installers will even handle upgrades, and thus, it's almost SaaS. However, it would still be nice to have SaaS with application support.
Tiki should be great for server farms, because people can customize a lot with same code base. Otherwise, users request various extensions/plugins and then, each install can have different files. See Hosting company.
Having both Open Source and hosted solution provides lots of benefits. (evolving platform, protection against vendor lock-in, etc.)
While their are tons of hosts (shared hosting, etc.) that can host Tiki Tiki Friendly Hosts, etc, no one is offering dedicated Tiki hosting at the moment, with 24/7 enterprise support.
Would need a way to be able to offer simplified admin panels (as started in Dynamic Preferences) Done in Tiki8
Learning curve will scare many away
Not clear how to get involved, who to talk to
All in one design makes it more challenging to start contributing. External modules in other apps can be very simple and easy to learn from, without bothering with big picture (at first, anyways)
Opportunities
Rick's blog is an "attempt to combat the Tribal Knowledge Syndrome that too often plagues software development projects"
Threats
Not having fresh energies could lead to staleness.
Recommended action
Make sure tiki-register.php is useable/useful
Better documentation and examples. Plugins and modules are great to learn from. Shoutbox is a good example as well.
Tiki has all the features so people will rarely have to give up on features if they choose to migrate
Weaknesses
Little availability or easy migration scripts
Opportunities
Most wikis are wikis only and most CMSs lack robust wiki functionality
To attract talent & energy to Tiki of people who love the wiki way but want/need more features. 2009 Google Summer of Code project!
Threats
Migration scripts tend to be fragile as developers only use them once.
Recommended action
Look into easing migration from specialized popular applications who do not intend to become full-featured systems (ex.: MediaWiki).
MediaWiki: support some of the syntax and improve import script.
First impression / New users / Ease of installation (C)
Once marketing worked and people do indeed decide to try it out. Priority of UX and Themes Team (for visitors and content editors) and Configuration Profiles Team (for site admins)
Strengths
Tiki has arguably more built-in (out-of-the-box) features than any other Web application so users that are looking for lots of features will be attracted.
3.x installer and general User Interface is much better than 2.x which itself much better than 1.9.x
Weaknesses
For years, the Tiki community has been very "developer-focused"
Clutter. Tiki has tons of features but it's too long/difficult to get started. "Obscure" features complicate implementation for would-be admins.
Enhance the profile manager and generate a profile for each of the most important Use Cases and encourage sub-communities around specialties / verticals Started for 3.0
This aspect is hindered by disorganization on *.tiki.org sites
When an active member is in need for support, "recognised consultants" should complete their mandate. Else, there should be a "notification system whereby some sort of management group about consultants" alerts other clients in regards to the level of reliability of the said consultant. Like a rating system.
Tiki is verythemeable.
Themes.tiki.org has good content and permits to test all themes with most features.
Weaknesses
Default themes are not as nice as other leading projects.
No commercial themes available
With all the features, some lack polish & focus
Themes.tiki.org is confusing (demo site vs doc site to install/create theme)
There is still some inline css style which is hard to deal for designers.
There are too much (but decreasing) tables used for presentation purposes.
The CSS structure of all the grids is not enough standardized. There are no guidelines for developers about which styles they have to use in which part of the pages. So, they use what they can or try to see in some other grids what is generally used. This is a main problem for newcomers. The community should deploy some efforts to deploy factorized tools (like smarty plugins) which leaves less initiative to coders when they have to choose a structure. Such plugins are well suited to the community which is very open to (quite) anyone.
Once we will have less bugs (we are not that far away), will come time to talk about ergonomy. There is A big big work to do. Our target has to be "one guy who knows nothing from wiki, web, etc... has to understand what he can do and what he has to do to achieve his work (change a wiki page, post in the forum...)". Today we are far away from this.... Developpers are, usually, not good in look and feel or ergonomy ! They often consider that the work is done when the functions are running and the buttons are working. Having a good look and feel is just another work.
Opportunities
With a little work, Tiki could be sexy.
Threats
People will use Wordpress or similar because there are hundreds of nice themes.
Recommended action
Setup a theme/UX and Themes TeamGary, luci, Patrick, ricks99, etc. are doing a great job
More user & centric design Done a bit for 3.0, more to come in 4.0
Would it be possible to write a script to batch convert Joomla! or Wordpress themes to Tiki? Maybe a script could do most of the job, finished by a designer.
For themes.tiki.org to be less of a theme testing place and more of a I-want-to-download-and-install type of place. demo.tiki.org could be used to test themes.
Perception of being "good" at many things, "excellent" at none.
People will use a collection of single-focus apps to solve their needs instead of Tiki. This is preventing a lot of new users & developers to join Tiki.
Without growth/recruitment, normal (natural) turn-over of volunteers will hinder Tiki development.
CMS Landscape is led by 3 major players and there are a bunch of specialized players. If Tiki doesn't maintain "mindshare", it could not be getting a steady stream of new energy to sustain and grow.
Make sure to stay at the top of the list (after the big 3) for activity level / mindshare / community size /etc of the CMS Landscape. Prepare Tiki vs Drupal pages for all the major ones.
Google says: "2. It's best to do one thing really, really well." but what if what you're really good at is to do lots of things? (A good all-round, well integrated tool?).
Better explain Where to find information and to participate.
By default, new t.o registrants are now taken to the Tiki Welcome page after registration.
Tiki has many indicators which are quite high
Activity Stats are high
Weaknesses
There is no tracking/alerts. If the number of committers/sites/contributors/etc increases or decreases
Data is fuzzy. Ex.: Number of active contributors: how do you define "active"?
Marketing Stats are low and only growing slowly
Tiki uses LGPL, which is a Standard OSI license
Active Legal Team
Weaknesses
Not able to re-use GPL code.
Tiki gathers many third-party components such as images, fonts and libraries. There is no systematic tracking of component licenses.
Opportunities
mods.tiki.org is a great way to help with GPL code
A clear licensing status of Tiki (and its components) would allow redistribution of Tiki by operating system vendors such as Debian.
Tiki data & code structure is pretty stable/mature now, so developing APIs now will ensure that they are fairly stable. Some developers want APIs, and maybe we'd get more traction. Ex.: plugin with Salesforce, etc
Interactions such as mashups are often low hanging-fruit
Making Tiki more 3rd party feature friendly could make the code more complex. (ex.: to be able to drop in phpBB instead of Tiki forums) [Adding migration tools for 3rd party apps like phpBB would bring more users, as would making it 3rd party friendly for less main-stream apps that would fit in modules]
Medium term: Have appropriate discussions about how to best get money, invest it, etc. Transparency, governance, etc And proceed with best solution, presumably to set up a foundation to handle this.
Do not engage in unsustainable spending
Add recurring revenue generating code in the application (optional of course). It would be a way for Tiki admins to help Tiki at no direct cost to them. It could be Google Adsense type ads visible to Everyone/Admins or no one. Think Firefox
Current *.tiki.org are split amongst several community members
Tiki has all the feature-set we could want and it's great DogFood dogfood is great long term strategy
Weaknesses
Not ready to scale to higher volumes, already doc.tw.o and dev.tw.o are straining current server
Lack of some tools like http://www.statsvn.org/
Lack of a dedicated team assigned to this aspect. Not all sites are kept to the latest version. dogfood can taste bad in the short term
Opportunities
Greater synergy with Open Source community by collaboration with organizations like Open Source Lab
I can personally attest that each new version of Tiki has gotten faster. 1.9 is clearly faster than 1.8, which is clearly faster than 1.7 ( I don't remember before that). Some indexes were added and some optimizations were done as bottlenecks were reached.
Tiki4: A new Performance admin panel was added to help people optimize.
Some proactive performance profile was done on Tiki5, and our YSLOW score was drastically improved with Minify JS and Minify CSS
Reality: we have no metrics to compare Tiki performance to other similar applications (Drupal, Mambo, etc).
Weaknesses
Tiki has a really bad reputation for performance because, for the longest time, tiki.org was hosted on a personal server. This server was underpowered and overloaded. Ever since Oliver Hertel took over tiki.org on a server from server4you.de, it has been zippy.
Reality: we have no metrics to compare Tiki performance to other similar applications (Drupal, Mambo, etc).
Opportunities
Large projects have been very helpful and will continue to be hugely helpful to identify real bottleneck with real data (vs some people interested in theory and worrying about performance bottleneck, which in reality, are not).
Threats
FUD: the same way it's difficult for other to prove Tiki is worse than another given app, it's very difficult for us to prove that Tiki is fast/scaleable.
Get someone in charge to get metrics and then, ask marketing to explain the situation, good or bad. It is ok to say "Tiki has way more features, but it's a bit slower".
Friendly challenge to our friends in other Open Source CMS and Wikis for a speed test / stress test challenge. This would be a great topic for a www.codefest.ws and collaborate on these aspects.
Good track record at fixing reported important security vulnerabilities.
All-in-one model makes it easy to test & duplicate security reports. (everyone has same features) Whereas 3rd party module model can make it tricky to check/test security or compatibility between two 3rd party modules.
In recent versions of Tiki, a security audit was done and we made sure that all .php files had a feature check and unless the feature is activated, the file does nothing, and can't be a risk. (So only activated features can be a risk).
A security script is part of the release procedure and detects potentially unsafe files.
Tiki is inherently pretty secure because it strips all javascript and doesn't interpret html. You can give html permission to a group however. (Drawback has been for usability)
Weaknesses
Users do not upgrade their Tiki
No formal guidelines on what is a security problem, so path disclosure bugs, while minor, are not systematically treated.
No systematic security audits.
All-in-one model makes for a security issue in a little used feature could still affect all Tiki installs. This is now solved by systematic feature check in all files.
Security team needs new fresh blood.
Tiki is so massive, that it's a lot of work to release new versions.
Not enough brainpower to maintain more than 2 BRANCHES. So we can't have a stable + security branch. We just have stable, which includes bug fixes and security fixes: Where to commit
Opportunities
By being more proactive, we'll avoid the annoyance of rush security releases.
Threats
Bad reputation because of security issues
Community members & Tiki users getting compromised
Recommended action
Since security is such a vast subject, identify some leaders for various aspects.
Put the finishing touches on the Security Dashboard document and make it public.
Start using TikiTests for systematic testing of risky areas.
Using profiles to turn off unsafe features (one-click where you are informed you need to upgrade)
Related links
Commercial support options / Paid support / Commercial opportunities (B)
There exists a growing market of full-time freelance Tiki Consultants, able to deliver installations that "just work" - for a price.
These consultants work well together and share back to the project when they can. Top-2 on WikiMatrix
Weaknesses
The small market lacks economies of scale, best practices are not transmitted, small outfits lack marketing, mgt and admin specialists.
Opportunities
Create an "un-corporation" - networks of solo/small shops that repeatedly contract each other - encourage specialization in vertical markets, roles, features. Build working relationships between developer teams. All developers become part of the network.
Threats
Conflicted interests among competing outfits. Struggle to get the biggest piece of a small pie - rather than focus on growing the pie.
Currently, Tiki has a lightweight decision-making process. Decisions are taken by consensus, where whoever does the work has more mojo If a vote is needed (which is very rarely the case), the Tiki Admin Group has "decisional" power. More on this at model. TAG is large enough, is composed of people with various backgrounds and yet, is highly cohesive (as of 2008-06). Social Contract
Weaknesses
Decisions and who does what are not clear for the community, especially newcomers.
Some community members could feel that they do not have sufficient influence. There could be doubts about transparency & governance. As of 2008-06, I see no evidence of any risk here.
A fork. Forks are usually very bad for everyone. Should be avoided as much as possible.
Spending too much time on politics and administration and forgetting that our focus is a a great community building a great community management system (software, the Wiki Way). Rules & guidelines are a means, not a goal.
As of 2011-09, doc team is having trouble with activity level
Features are developed/improved faster than the documentation can keep up to date.
While some pages are of excellent quality, overall navigation is confusing for new users.
Too many links on doc.tiki.org
Structure hard to keep up to date
Opportunities
Snapshot documentation on each release and somehow allow users to import it into their own Tiki installs so the help is local. Would probably be a boon for folks in Australia for example, that get redirected to doc.tw.o when they click on a help icon for something. May require reformatting or reorganizing the doc site, but can see huge advantages for people who don't run the SVN version.
Threats
The move from 1.9.x to 2.x to 3.x is a challenge. How to efficiently manage the three versions?
Current Editorial Board needs new energy
In recent versions, a note warns admins of new versions.
Weaknesses
People don't upgrade. We find people with 2-3-year-old Tikis
We don't know how many installs there are and what features people are using. We can't pull out a feature, confident that almost no one will be affected.
Opportunities
A larger install base could bring more energy to the project, in particular, if we include invitations to participate and promotional links in default templates.
Web 2.0 is often associated to concepts/features that are built-into Tiki, such as wikis, blogs, RSS, folksonomy, etc. It was quite ambitious to add all of them in an app, and they are all there, stable and tightly integrated
Wikis have proven staying power (What else than a Wiki could power Wikipedia?)
Diverse commercial ecosystem (vs 1 main company backing the project)
Not fragile to loss of venture-capitalist funding
Everything thought/planned in a p2p sustainable way
Tiki is a community effort and can't be sold and changed to a lock-in model (license, etc.)
Weaknesses
Community, install base and bus factor is not quite large to guarantee long-term sustainability
Opportunities
Improving browsers and HTML5
Threats
While it feels unlikely now, there could be new technologies that render PHP apps like Tiki obsolete (And would render WordPress, Joomla! and Drupal obsolete as well)
While it inconceivable that new technologies will render browser-based computing (very long term) 10+ years if ever, there could be a shift to how we generate them.
Suitable infrastructure (UTF8, etc.) to support more languages
Weaknesses
Nobody in charge so we have no up to date metrics on the state of our translations.
Could be easier to translate
No one is actively coordinating with translators.
Opportunities
Opportunity for growth in l10n where Tiki would have a local advocate.
Threats
None really, just lost opportunities
Recommended action
Setup an i18n Team and i18.tiki.org in collaboration with the use of maps.
PHP/MySQL/Smarty were excellent design choices 10 years ago and they still are today. Tiki has been able to leverage these re-use their experience.
Tiki's current infrastructure has supported a huge number of features.
All-in-one structure makes it both easier and more difficult to evolve.
Newer additions of PDO, Zend_Framework and jQuery improve Tiki without more code overhead.
Weaknesses
All-in-one structure makes it both easier and more difficult to evolve.
Easier because we can change everything
More difficult because we take everything into account
Code is messy in a lot of places, which makes the Code Infrastructure an area that needs improvement to better support new features. Solid code base, but hard to understand sometimes. Lack of coding documentation (like phpDoc or Doxygen) and enforcement.
There are many code duplication in many parts. This makes the code easy to read (which is a strength) but gives a code which is hard to evolve easily. A big amount of work was done (eg on trackers) but there is still a big work to do.
All the css stuff is not enough standardised all over the code. Some work was done on that point and now titles, or buttons have more or less the same css structure. But, there is still many to do.
Much faster release cycle than other similar apps. Tiki is now 6-month release while many others are 18-24 months
2009-05: Tiki3 LTS
2009-11: Tiki4
2010-06: Tiki5
2010-11: Tiki6 LTS
2011-06: Tiki7
2011-11: Tiki8
2012-06: Tiki9 LTS
2012-12: Tiki10
2013-07: Tiki11
2013-10 (planned): Tiki12 LTS
Our packaging expert (changi) is on top of things!
More promotion by frequent releases
Fast release schedule is great for consultant ecosystem.
Weaknesses
Much too long cycles between 1.9 and 2.0 releases Solved
Tiki is no longer included in distros such as Debian
No PPA, .deb or RPM
Opportunities
In a few years, we could start thinking of a 4-month release-cycle, but as of 2012, there is no benefit.
Threats
People get discouraged because the feature they coded a long time ago in 1.10 is not yet in stable release. Solved Other applications have wanted features in stable release. Solved as we now are very responsive to new opportunities
A threat is to lose focus and the cadence, but this is quasi-impossible because this is now part of the DNA of the community. The releases could become smaller in terms of new features because more & more people have all that they need, but that is OK and we'll always have enough to warrant new releases.
Not well enough explained/documentation how to make a theme, and still make it easy to upgrade.
Prevents us from removing features.
Opportunities
Good PR, because this is an advantage over many other systems.
In 3.0, update script handles database operations better
Threats
When people don't upgrade their Tikis, they can get compromised and it's bad for everyone.
Recommended action
Improved documentation about upgrading Tiki
Possibly split tiki-install to have a tiki-upgrade.php
Adding an RSS feed or some sort of warning system to inform Tiki admins to update. (like Zencart) This RSS feed could be on the main admin page and give infos coming from info.tiki.org.
Friendly
Excellent collaborative spirit
Many people have been active for a very long time
Easy to join the project and to contribute: How to get commit access
Weaknesses
While it is sizable, it's too small for a project this size.
Too few people are taking on specific responsabilities
Opportunities
As long as we organized in a scalable way, the more the merrier.
Number of bugs is proportional to number of features
Weaknesses
A big strain of dev team for releases. (too much code vs developers)
Difficult to know who maintains what.
Buggy features are bundled in release and not all tagged as experimental
So many features make it difficult to focus. What if I don't want a toolset, but a specific tool?
Have a way to clearly identity all experimental features/settings (as of now, it's just first level. No easy way to see if subfeature of X is experimental
We eat our DogFood for almost everything. This ensures that our community and the code moves cohesively. Our community and eating our own Dogfood are the two most important things.
Weaknesses
Our tools are not always good for everything, especially at first.
Opportunities
To improve Tiki and efficiency of our community members.
Threats
Wasted time as we are sawing the branch we are sitting on.
Recommended action
Continue!
Re-converge community-focus on tiki.org and keep dev.tiki.org just for dev stuff
This SWOT should stay high-level and most of the specifics should be moved to the relevant Teams or project page.
Should events be its own section?
Should we have an "Enterprise-readiness" section?
Make a new section with reliability & stability (regressions, testing, eyeballs, bug density)
Should "standards" should go with "Extensibility / Expandability / Mashups / Integration with 3rd party apps & code reuse"
Should we split the "Installation" and add a new section "the first 30 minutes"?