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 Where is Tiki headed? Please see: Goals |
|
Goals of this page:
- A community-managed S.W.O.T. for the Tiki community
- A lightweight participative strategic planning tool
- Dogfood the use of Tiki for this purpose (SWOT analysis the wiki way!)
- Two additional sections "Recommended actions" and "Related links" have been added.
- This page will be in constant flux and will evolve as things get done, and as opportunities/threats arise.
- Let's keep this for high-level big picture stuff. Bug reports and feature requests should stay on dev.tiki.org
- This could evolve into better risk analysis, gap analysis and mindmap tools in Tiki. 😀
Rating System
| ||
A | Excellent | These are our strengths. Let's make sure it stays that way. |
B | Very Good | Things are generally under control |
C | Good | Could be better, but no immediate problem |
D | Poor | Needs some TLC |
E | Fail | OMG there is something terribly wrong here! Someone should do something about it. How about you? 😉 |
Reality check: As a volunteer organization, just adding something as a high-priority doesn't magically make it get done. It is useful nonetheless for:
- The community to have a global vision.
- People evaluating Tiki as a project & community to know what to expect
- For new people to see where help is most needed
- Ratings are a combination of importance vs difficulty which give us a very subjective Priority
- Think "A chain is only as strong as its weakest link."
- Something could be easy to fix and will be high priority even if it's not the most important (quick wins, low-hanging fruit)
- Something could be very important, but the solution is not obvious.
- Some things will help several things and should be done first. (bottlenecks)
- Some things take a long time to produce results and thus, should be started early.
- This is sometimes compared to other Open Source applications, sometimes a judgment on our evolution
- We'll sort the worst things (E to A) at the top to remind us that someone (you? 😉) should do something about it 😊
- The main thing is to keep the main thing the main thing.
- We can and must choose to see the glass as half-full. However, we must be realistic about the situation so we can improve.
Table of contents
- Easy Hosting / SaaS / Hosted solutions / Wikifarm (D)
- Teams / Working groups / Special interest groups / local user groups / p2p leadership (C)
- Integration of new contributors to the community (D)
- Migration to Tiki (C-)
- First impression / New users / Ease of installation (C)
- User Experience / Look & Feel / Themability / User interface / Usability / Ease-of-use (C)
- tiki.org Information / Promotion / Marketing / Public Relations (C)
- Dashboard / Stats / Metrics / Key Performance Indicators (KPI) (C)
- Licensing / Legal (C)
- Extensibility / Expandability / Mashups / Integration with 3rd party apps & code reuse (C)
- Relations with the outside World / Standards / participation to events (C)
- Money and Fundraising (C)
- Sites & infrastructure (C)
- Customizability / Hackability (B)
- Performance / Scalability / Server load (B)
- Security (B)
- Commercial support options / Paid support / Commercial opportunities (B)
- Total cost of ownership (TCO) (B)
- Decisional structure / Governance / Guidelines / Rules / Strategic planning (B)
- Documentation (C)
- Install base / Adoption (C)
- Long term sustainability / Future-proofness / Lock-in protection (B)
- i18n / translations (B)
- Components / Platform independence / Code infrastructure / Architecture (B)
- Lifecycle, releases and packaging (A)
- Upgradeability (A)
- Community / Volunteers / Free support (A)
- Features / Development / Stability / Interoperability (A)
- Eating our own Dogfood (A)
Easy Hosting / SaaS / Hosted solutions / Wikifarm (D)
Priority of the Packaging Team.
|
|
|
|
|
|
Teams / Working groups / Special interest groups / local user groups / p2p leadership (C)
Priority of Tiki Admin Group and Community Building Team
Tiki as an app has pretty much all the features to support this. |
Too few functional Teams. |
Growth Easier integration of newcomers DogFood for Social Networking |
Without teams, the organization can't scale |
|
http://shirky.com/writings/group_enemy.html http://en.wikipedia.org/wiki/Dunbar_number http://www.lifewithalacrity.com/2004/03/the_dunbar_numb.html http://www.spring.org.uk/2009/07/10-rules-that-govern-groups.php http://www.wikisym.org/2009/08/10/wikisym-2009-keynote-community-performance-optimization-making-your-people-run-as-smoothly-as-your-site/ |
Integration of new contributors to the community (D)
Priority of Community Building Team and Wishlist Triage Team (because they see the good bug reports and patches)
|
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) |
Rick's blog is an "attempt to combat the Tribal Knowledge Syndrome that too often plagues software development projects" |
Not having fresh energies could lead to staleness. |
|
|
Migration to Tiki (C-)
Priority of the Consulting Ecosystem Team.
Tiki has all the features so people will rarely have to give up on features if they choose to migrate |
Little availability or easy migration scripts |
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! |
Migration scripts tend to be fragile as developers only use them once. |
|
|
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)
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 |
|
By leveraging all the features with better profiles, the community would grow faster.
|
|
|
Featuritis vs. the Happy User Peak |
User Experience / Look & Feel / Themability / User interface / Usability / Ease-of-use (C)
Priority of UX and Themes Team
Tiki is very themeable. Themes.tiki.org has good content and permits to test all themes with most features. |
|
With a little work, Tiki could be sexy. |
People will use Wordpress or similar because there are hundreds of nice themes. |
|
Featuritis vs. the Happy User Peak |
tiki.org Information / Promotion / Marketing / Public Relations (C)
Priority of Communications Team, Branding Team and Consulting Ecosystem Team.
|
|
Getting lots of new, outside energies into Tiki. |
|
|
|
Dashboard / Stats / Metrics / Key Performance Indicators (KPI) (C)
Priority of Analytics Team and Tiki Admin Group
Tiki has many indicators which are quite high Activity Stats are high |
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 |
DogFood a new feature in Tiki. |
Not having good data to work with or spending too much time collecting |
|
|
Licensing / Legal (C)
Priority of Legal Team
Tiki uses LGPL, which is a Standard OSI license Active Legal Team |
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. |
|
|
|
|
Extensibility / Expandability / Mashups / Integration with 3rd party apps & code reuse (C)
Priority of Developers Team
|
|
|
|
|
|
Relations with the outside World / Standards / participation to events (C)
Priority of the Communications Team and Tiki Admin Group
|
Tiki is not good enough at marketing and needs to be more outward facing, and in contact with various actors of the Open Source World. |
Participating to more standards. More synergy Unexpected opportunities |
Lost opportunities & isolation |
We should apply again in 2009 for Google Summer of Code. Accepted!! 4 projects! Be more active in standards and associations, such as OSCOM http://www.advogato.org/article/544.html http://www.advogato.org/article/657.html
|
|
Money and Fundraising (C)
Priority of Fundraising Team and Finance Team.
The Tiki association has a bank account. Easy to make donations at http://tiki.org/Donation |
While there are occasional sources of funding, there is no major recurring revenue. |
|
|
|
http://producingoss.com/en/producingoss.html#money http://www.spi-inc.org/about/ |
Sites & infrastructure (C)
Priority of Dogfood Team and Infrastructure Team
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 |
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 |
Greater synergy with Open Source community by collaboration with organizations like Open Source Lab |
Disappointing new people as load increases |
|
http://docs.joomla.org/Sites_and_Infrastructure_Working_Group |
Customizability / Hackability (B)
Priority of Developers Team
|
It's so vast that there is a learning curve. Because of alternate code model (wiki way, all-in-one), people don't always get it right away |
|
Code changes that will make Tiki less hackable |
Improve Hello World |
|
Performance / Scalability / Server load (B)
Priority of Performance Team
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). |
Reality: we have no metrics to compare Tiki performance to other similar applications (Drupal, Mambo, etc). |
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). |
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. |
|
|
Security (B)
Priority of Security Team
|
|
By being more proactive, we'll avoid the annoyance of rush security releases. |
Bad reputation because of security issues Community members & Tiki users getting compromised |
|
|
Commercial support options / Paid support / Commercial opportunities (B)
Priority of the Consulting Ecosystem Team.
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 |
The small market lacks economies of scale, best practices are not transmitted, small outfits lack marketing, mgt and admin specialists. |
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. |
Conflicted interests among competing outfits. Struggle to get the biggest piece of a small pie - rather than focus on growing the pie. |
Short & Medium term: Grow the Pie 1- Identify & promote Tiki service providers. Started at http://info.tiki.org/Consultants and http://www.wikimatrix.org/consultants/Tiki+Wiki+CMS+Groupware/ 2- Ask these service providers to prepare some guidelines, like a code of conduct of vendors For example: http://typo3.com/Consultancies.1248.0.html http://drupal.org/drupal-services Encourage presence of firms like Citadel Rock at events like Web 2.0 Expo Start a guide to Tiki consulting: best practices
Medium term:
|
|
Total cost of ownership (TCO) (B)
Priority of the Tiki Admin Group
Thinking of open source like free kittens/puppies, it is necessary to allocate time for maintenance.
|
|
|
|
|
http://en.wikipedia.org/wiki/Total_cost_of_ownership |
Decisional structure / Governance / Guidelines / Rules / Strategic planning (B)
Priority of Community Building Team and the Tiki Admin Group.
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 |
|
Dogfood Tiki to become a better E-Democracy system |
|
|
http://meta.wikimedia.org/wiki/Wikipedia_power_structure http://en.wikipedia.org/wiki/Strategic_planning http://en.wikipedia.org/wiki/Open_source_governance http://producingoss.com/en/producingoss.html#social-infrastructure http://webmink.com/essays/open-by-rule/ http://www.oss-watch.ac.uk/resources/governanceModels http://www.oss-watch.ac.uk/resources/ssmm |
Documentation (C)
Priority of Documentation Team
The documentation is "Good, but could be better.". All in the wiki, and with occasional snapshots to PDF. Easy to point to a specific page. |
|
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. |
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 |
|
|
Install base / Adoption (C)
Priority of Communications Team, Consulting Ecosystem Team and Packaging Team.
|
|
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. |
Security issues because people don't upgrade. |
|
http://en.wikipedia.org/wiki/Product-Market_Growth_Matrix |
Long term sustainability / Future-proofness / Lock-in protection (B)
Priority of the Tiki Admin Group.
|
|
Improving browsers and HTML5 |
This is only a threat if we (Tiki, PHP, etc.) don't adapt. |
|
|
i18n / translations (B)
Priority of i18n Team
|
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. |
Opportunity for growth in l10n where Tiki would have a local advocate. |
None really, just lost opportunities |
|
http://docs.joomla.org/Translations_Working_Group |
Components / Platform independence / Code infrastructure / Architecture (B)
Priority of Developers Team
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. |
|
TikiObject Use Tiki more & more as Framework HTML5 |
The hype with new languages. Yet PHP is ahead http://www.ohloh.net/articles/php_eats_rails http://www.ohloh.net/tags/programming_language |
|
|
Lifecycle, releases and packaging (A)
Priority of Packaging Team and Release Team
|
Tiki is no longer included in distros such as Debian No PPA, .deb or RPM |
|
|
|
|
Upgradeability (A)
Priority of Developers Team and Packaging Team
|
|
|
When people don't upgrade their Tikis, they can get compromised and it's bad for everyone. |
|
|
Community / Volunteers / Free support (A)
Priority of Community Building Team
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 |
While it is sizable, it's too small for a project this size. Too few people are taking on specific responsabilities |
As long as we organized in a scalable way, the more the merrier. |
Since the beginning of the project, there have been a handful of individuals which have caused lots of negative vibe. It could happen again. How Open Source Projects Survive Poisonous People (And You Can Too) |
On a defensive side, give officially the TAG the responsibility to warn, reprimand and then, expel these Poisonous People On the positive side, maybe a community team. This team would play a bit the role of human resources in a company. "recruit early, recruit often"
|
http://producingoss.com/en/producingoss.html#managing-volunteers http://eaves.ca/2007/02/05/wikis-and-open-source-collaborative-or-cooperative/ http://www.alwaysdoneitthatway.com/2007/10/21/six-principles-for-designing-an-architecture-of-participation/ http://www.principledinnovation.com/blog/2008/05/17/cognitive-surplus-and-new-incentives-for-engagement/ |
Features / Development / Stability / Interoperability (A)
Priority of Developers Team and Continuous Integration Team
|
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? |
Major Features Missing In Tiki Trackers and Profiles will permit to increase features while keeping the code base manageable. |
A Software Engineering Odyssey -> NT 3.1 vs Windows 2000 story |
|
|
Eating our own Dogfood (A)
Priority of Dogfood Team
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. |
Our tools are not always good for everything, especially at first. |
To improve Tiki and efficiency of our community members. |
Wasted time as we are sawing the branch we are sitting on. |
|
|
http://www.typo3-swot.com/
http://plone.org/events/2008-summit/customer-segments-swot-analysis
http://wiki.services.openoffice.org/wiki/Strategic_Marketing_Plan#SWOT
http://bugs.sakaiproject.org/confluence/display/CONF09/Sakai+SWOT+Analysis
- http://en.wikipedia.org/wiki/Open_source_software_assessment_methodologies
- How to Evaluate Open Source Software / Free Software (OSS/FS) Programs by David A. Wheeler
- http://producingoss.com/
- Community Projects
- Teams
- Ease Importance Priority
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"?