Support/TikiWikiUpgrade

Our three options

Upgrade

Upgrade to the latest stable version of TikiWiki and upstream future patches to ensure that we can continue to upgrade on each major TikiWiki release with minimal headache.

Pros

• We can take advantage of the new TikiWiki features, such as Profiles (will allow us to create an "open source support" profile for TikiWiki that will be customized for the support website use case)
• SUMO community will be accustomed to all website tools, including things like the wiki markup
• Will pave the way for a healthy relationship with the TikiWiki community
  • More visibility of our SUMO-specific features (e.g. the l10n dashboard) since they'll be available to other projects too
  • We will become an actor instead of a consumer of TikiWiki -- our opportunity to give back to TikiWiki and demonstrate true Mozilla and open source values
  • Opportunity to share our experiences and insights about secure and efficient coding to change TikiWiki developers' mindset
• Support/BenefitsOfUpgradingToTiki4
• Tiki has a predictable release schedule (twice per year) and each version will have features that are useful for SUMO, even if they weren't high enough on priority list to actually develop them.
• Tiki project wants to have all the SUMO functionality discussed so far in Tiki core, and have available easily for anyone in next release. Full agreement on Support/SumoDevRoadmap2009 and we can presume that synergy in goals will always be there.
• Tiki community members have volunteered in the past and have upstreamed stuff when put to their attention
  • Themes: Gary & luci have volunteered to make 4.x version and to work with SUMO to genericize interesting things. Ex.: Since 1.10, there several new fields (ex.: Site title subtitle, footer, etc.) that can managed via the admin panel (tiki-admin.php?page=look). And with workspaces, it becomes possible to override them by perspective. Site footer when user picks Fennec perspective is different the general site footer. (New in 4.0). It will be ready for September 11th here: http://sumo.ourwiki.net/ and in SVN (We'll make a branch)

Cons

• TikiWiki 4.x still has several major design flaws -- our best bet in the long term would be to rewrite some of these components to allow future scalability and extensibility
• During the initial upgrade to 4.x, making sure that everything still works on SUMO will mean extensive QA and likely several bug fixes aside from our initial list of patches to upstream.
• Once we've upgraded to 4.x, we will need to keep upstreaming our patches to TikiWiki trunk to ensure that our new features and bug fixes will be available when we upgrade TikiWiki to 5.x, 6.x, etc.
• TikiWiki and SUMO often has quite different priorities. TikiWiki wants to create the equivalent of a CMS "operating system" -- a solution that can do pretty much anything. Our focus is to produce a high quality solution designed to fit our needs.

Fork

Fork and leave TikiWiki behind altogether and develop our own solution independently of TikiWiki.

Pros

• We could easily strip out 90% of the codebase
• We could probably still "steal" new TikiWiki features if we wanted to by backporting
• We could eventually rewrite major components and slowly get rid of our TikiWiki dependencies
• No need to upgrade to the latest version of TikiWiki or upstream our future patches

Cons

• We would still have to rewrite many of the components to ensure future scalability, but rather than working together with TikiWiki we would do it on our own
• We could hardly call ourselves good open source citizens since we wouldn't give any of our fixes or feature additions back unless someone took our code and upstreamed it themselves

Port

Port SUMO to a different platform.

Pros

• We could switch to a platform that focuses on scalability, performance, and extensibility, rather than a "Jack of all trades, master of none" platform
• No need to upgrade to the latest version of TikiWiki or upstream our future patches

Cons

• Unless we invested a crazy amount of time to make things feel unchanged, this would mean a radically different system for many of our community members' use cases:
  • Editing articles would likely be done with a different wiki syntax
  • Localization workflow would be different
  • Forum software would be different
• This would definitely disrupt and alienate many SUMO community members who typically aren't excited about changed workflows -- just getting people to contribute on SUMO rather than another system has proved to be very difficult in the past
• Would essentially mean that all further SUMO development would stop for a good amount of time (probably a full quarter at best)
• Not clear how much of a benefit this would be in the end -- depends heavily on the platform chosen
• Would likely have tons of regressions and broken use cases we didn't consider

What's needed to make a decision

• Meeting with James/Laura/David/Marc/Paul for James to share some new architecture concerns and get to know each others' perspectives more -- Sept 2nd
• Table of technical comparison between different CMS platforms (James)
• Meeting with James/Laura/David/Marc/Paul/LPH so LPH can provide some initial responses on the feasibility of our architectural ideas
• Completed work on SUMO bug triage to get a clear picture of resources needed to upgrade (David/Laura/Marc)
• Response to our architecture concerns (LPH/Marc) -- due Sept 9th