介绍

Tiki成立于2002年具有最内置功能的FLOSS Web应用程序也许从2005年或2006年开始。从一开始，Tiki就被设计/注定具有许多功能。裁判：SourceForge.net月度项目，2003年7月.

在早期，许多web应用程序只有一个“主要”功能，例如，PhpWiki网站和菲律宾比索特别是在Tiki的早期，一些人（社区和祝福者）表示担心，拥有所有这些功能和如此雄心勃勃的目标是一个巨大的风险。从本质上讲，人们担心的是：“是的，它现在可以在小范围内工作，但随着更多功能的添加，复杂性增加，它最终会内爆并陷入停顿。”

2011年6月，在讨论时名为Tiki Suite（后来更名为WikiSuite（维基套件）)有人指出了这些担忧。我多年没有听到过，我想Tiki的描述模型和Tiki一起成功多年来，这些担忧已经平息了。然而，当一个人表达担忧时，很可能代表了更多默默思考的人。因此，本页旨在

1. 解释Tiki在历史上如何应对复杂性
2. 推测一下如果/当我们遇到困难时会是什么样子，以及
3. 总的来说，提供如何避免未来困难的想法。

一位维基百科人曾被引用：“维基百科的问题在于它只在实践中起作用。理论上，它永远不会起作用。”Tiki有很多相似之处，一些人认为它永远不会工作，或者无法扩展。

注意：在本讨论中，术语“扩展”、“模块”、“插件”和“插件”都是同义词，指的是不属于主（核心）代码库的代码。这些在web应用程序中的使用非常普遍。

定义概念

这不仅仅是一个代码复杂性问题。这也是一个社区管理问题，它影响文档等等。

“争论的核心是偶然复杂性和本质复杂性之间的区别。偶然复杂性与我们自己创造的、可以修复的问题有关；例如编写和优化汇编代码的细节或由批处理引起的延迟。本质上的复杂性是由要解决的问题引起的，没有什么能够消除它；如果用户想让一个程序做30件不同的事情，那么这30件事情是必不可少的，程序必须做这30件不同事情。"
http://en.wikipedia.org/wiki/No_Silver_Bullet

“在技术战略中，棋盘的后半部分是由Ray Kurzweil创造的一个短语，指的是指数增长的因素开始对组织的整体商业战略产生重大经济影响的时刻。”
http://en.wikipedia.org/wiki/Weat_and_chessboard_problem#黑板的第二部分

“软件工程中使用了软件彼得原理来描述一个濒临死亡的项目，这个项目一点一点变得过于复杂，甚至自己的开发人员也无法理解。它在业界被称为项目的无声杀手，当症状出现时，往往为时已晚。优秀的管理者可以通过建立明确的编码实践来避免这种灾难，从而避免不必要的复杂代码和设计。名字是。源自彼得原理——一种关于等级组织中无能的理论”
http://en.wikipedia.org/wiki/Software_Per_principle

“范围经济在概念上与规模经济相似。而企业的规模经济主要指平均成本（单位成本）的降低范围经济与增加单一产品类型的生产规模相关，是指降低企业生产两种或两种以上产品的平均成本。"
http://en.wikipedia.org/wiki/Economies_of_scope

相关链接：

• http://en.wikipedia.org/wiki/Anti-pattern网站
• http://en.wikipedia.org/wiki/Software_blot
• http://www.zdnet.com/blog/service-oriented/avoid-accidental-complexity-and-96-other-things-every-software-architect-should-know/2436

这方面的例子有哪些？

遇到此类问题的项目是如何应对的？他们丢了一些球吗？他们把项目分割了吗？我们可以学习什么来避免这些问题？

赫德

资料来源：模块化设计和复杂工件的开发：自由/开源软件的经验教训（2003）作者：Alessandro Narduzzo和Alessandra Rossi

很难将web应用程序与内核进行比较，但如果可以进行比较，Tiki的统一方法更接近Torvalds方法。

“Mach微内核给HURD开发人员带来了难以克服的问题，尽管Tanenbaum和其他人提出了批评，但为Linux选择单片内核使其更容易满足所有自由软件开发人员的首要要求，这是一个可以工作的自由操作系统。”
资料来源：http://www.h-online.com/open/features/GNU-HURD-Altered-visions-and-lost-promise-1030942.html？page=3

弹性搜索

资料来源：http://www.theregister.co.uk/2014/12/23/elasticsearch_big_data_search_tool_fancy_an_elk_hunt/？page=2

谷歌

• http://www.wired.com/2015/09/google-2-billion-lines-codeand-on-place（网址：http://www.wired.com/2015/09/google-2-billion-lines-codeand-on-place）/
• http://m.cacm.acm.org/magazines/2016/7/204032-why-google-store-billions-of-lines-of-code-in-a-single-repository/fulltext
• https://www.youtube.com/watch？v=W71BTkUbdqE
• http://danluu.com/monorepo/

还有其他例子吗？

为什么事情变得复杂？

缠绕性

一切都被深深地交织在一起。在一个重要的意义上，根本没有“主体”；只有所有的知识，因为这个世界上无数主题之间的交叉联系根本无法整齐地划分。等级和顺序结构，尤其是自古腾堡以来流行的结构，通常是强制的和人为的。人们普遍不承认缠绕现象——人们总是假装自己可以使事物层次化、分类化和有序化，而事实并非如此。-特德·纳尔逊
http://en.wikipedia.org/wiki/Interntwingularity（维基百科全书）
http://shirky.com/writings/ontology_overrated.html
http://en.wikipedia.org/wiki/Ted_Nelson

虽然Ted Nelson创造了“Intertwingularity”来表达“人类知识中相互关系的复杂性”，但软件也是同样的问题。总是会有重叠特征和用例例如学习管理系统有一些功能重叠（例如：用户系统和日历）群件因此，与维护两个应用程序相比，在群件中添加缺少的功能（例如：成绩册）要简单得多。因此，随着Tiki为每个版本添加功能，覆盖各种用例（范围经济）变得越来越容易。

依赖地狱

“依赖地狱（Dependency hell）是一个口语术语，指一些安装了依赖于其他软件包特定版本的软件包的软件用户感到沮丧。”
http://en.wikipedia.org/wiki/Dependency_hell

Tiki的最终用户对此几乎免疫，因为所有代码都在核心中。所有功能同时发布。然而，Tiki开发社区需要处理这一问题，因为它包括来自作曲家Tiki的策略是尝试使用最新版本的软件库来保持主干，并使用最新的需求来进行创新。例如，在2017年年中，WordPress需要PHP 5.2，而Tiki需要PHP 5.6。请参见：版本生命周期.

扎文斯基定律

Zawinski的软件包络定律（也称为扎文斯基定律)将流行压力与软件膨胀现象联系起来。

“每个程序都会尝试扩展，直到可以读取邮件。那些无法扩展的程序会被能够扩展的程序取代。”

应对扎温斯基定律

当飞机坠毁时，我们会责怪地心引力吗？我们必须应对！

• 《变成现实》一书中有37个信号：“别再膨胀了。简单、专注的软件只做你需要的，没有你不需要的。”
• “专注就是说不”——史蒂夫·乔布斯（1997年WWDC）

在社区FLOSS项目中，很难就什么是“需要”，什么是“膨胀”达成共识

解释一下Clay Shirky，可解决的问题不是功能过载，而是更好的过滤器。

因此，您的下一个选择是拥有像Drupal和Joomla那样的扩展系统！或一个一体式模型就像Tiki。

过了一段时间，一些功能获得了如此多的选项，以至于它变成了意大利面（在UI、代码或两者中）。发生这种情况时重构很重要。Tiki模型允许在不放弃部分社区的情况下在版本之间进行重大更改。请参见：适应性.

组合爆炸

在数学中，组合爆炸描述了由于组合考虑而迅速增长的函数的效果
http://en.wikipedia.org/wiki/Combinatorial_explosion

随着功能列表的增长，所有东西都有望与其他东西交互，可能出错的事情数量迅速增加。当有几个用于类似目的的扩展时，这会增加更多的复杂性。

在几乎独立的子问题中分解复杂问题本身就是一项复杂活动

对于复杂度和具有太多功能的软件，有些人会指出其哲学：做一件事，做好它。

“管理学和计算机科学的文献都清楚地指出了模块化设计的利弊，我们已经讨论了设计师在为复杂系统发明模块化架构时所面临的被低估的困难。与Simon的观点一起，已经表明复杂问题的分解在几乎独立的子问题（即模块）中，本身就是一项复杂的活动（Marengo等人，2001年）。一开始，设计者不知道如何准确地将新工件的模块概念化；后来，当达到第一个概念化时，他们仍然模糊地知道所选架构与未考虑的架构相比有多好。"
资料来源：模块化设计和复杂工件的开发：自由/开源软件的经验教训（2003）亚历山德罗·纳杜佐和亚历山德里·罗西

我们能应付多大的复杂性？

很难说。没有数学公式！但在全球范围内，社区越大、越多样化、越活跃、越协作，我们能够应对的复杂性就越大。

• 更多的功能和更多的代码带来了更多的复杂性。
• 更多眼球帮助应对复杂性。
• 更多的功能会带来更多的用户，从而吸引更多的眼球。
  • 要么该软件的当前用户继续使用它而不使用其他东西，要么长长的功能列表吸引了人们。
  • “本质上的复杂性是由要解决的问题引起的，没有任何东西可以消除它；如果用户希望程序做30件不同的事情，那么这30件事情是必要的，程序必须做这30件不同事情。”-http://en.wikipedia.org/wiki/No_Silver_Bullet

我们也无法预测协作社区的适应能力。维基百科在不到20年的时间里成功地收集了比其他任何东西都多的知识。很少有人预测能在目前的水平上取得成功。

“维基百科的问题在于它只在实践中有效。理论上，它永远不会起作用。”

Tiki“只有”超过300个代码贡献者(请参阅列表所有代码贡献者）和许多其他项目已经证明，FLOSS可以扩展到比邓巴编号.

我们应该注意哪些症状？

这是一件很难判断复杂性在哪一刻“接管”的事情，也许当你看到它的时候，很难扭转方向。

创新放缓

如果由于需要考虑的所有因素，添加新功能变得如此耗时，该怎么办？

近年来，由于Tiki的改进web应用程序变得越来越容易创新比以往任何时候都容易。

提交统计演变

如果提交统计数据开始下降（Tiki不是这样），是因为复杂性还是因为功能更稳定？

代码库增长速度超过社区

如果您查看代码行（LOC）计数（这不是一个很好的度量标准，我同意，但只是为了说明），您将看到Tiki的LOC数量在逐渐增长，而Drupal/Joomla/WordPress项目的扩展/插件需要处理成倍增长的代码库。我的观点是，这是由扩展中的功能重复引起的（这通过指数组合带来了复杂性）

随着所有新增功能的增加，Tiki LOC数量增长缓慢。此外，我们定期进行重构，以简化和减少代码库。源代码行

正确看待事物

Tiki 12.2安装包含14803个文件具有最内置功能的FLOSS Web应用程序.

Tiki中大约一半的代码由Tiki社区维护，另一半是重新使用来自外部库如Smarty、Zend Framework、jQuery等。这些通常位于/vendor_bundled中：7511个文件（随着时间的推移，一切都被转移到作曲家，因此SVN或SVN外部中的外部代码越来越少）。

因此，Tiki社区保留了剩下的：7292个文件.

假设我们维护了大约7000个文件。听起来有点像，但让我们从长远来看：

• 乔姆拉！有8351个“分机”
• Drupal有27604个“模块”
• WordPress有32 912个“插件”

Tiki涵盖了这三个系统通过数千个扩展提供的绝大多数功能。所以你可以用Joomla做任何项目！，WordPress或Drupal，你也可以使用Tiki。

然而，他们需要维护的扩展比我们的文件还要多！（而且由于他们不可能维护所有的扩展，这导致了死扩展和最终用户失望）。

此外，比较Tiki和Drupal代码库您将看到我们正在出色地应对复杂性。

释放速度变慢或更困难

Tiki不仅是拥有最多内置功能的网络应用程序，在过去10年中，没有其他主要的CMS/网络应用程序发布过更多的主要版本：

• 2009-05:http://doc.tiki.org/Tiki3网站LTS公司
• 2009-11:http://doc.tiki.org/Tiki4网站
• 2010年6月：https://doc.tiki.org/Tiki5网站
• 2010-11:https://doc.tiki.org/Tiki6网站LTS公司
• 2011-06:https://doc.tiki.org/Tiki7网址
• 2011-11:https://doc.tiki.org/Tiki8网站
• 2012-06:https://doc.tiki.org/Tiki9LTS公司
• 2012-12:https://doc.tiki.org/Tiki10
• 2013-06:https://doc.tiki.org/Tiki11
• 2013-10:https://doc.tiki.org/Tiki12LTS公司
• 2014-8:https://doc.tiki.org/Tiki13
• 2015-5:https://doc.tiki.org/Tiki14
• 2016年4月：https://doc.tiki.org/Tiki15LTS公司
• 2016-11:https://doc.tiki.org/Tiki16
• 2017-7:https://doc.tiki.org/Tiki17
• 2018-1:https://doc.tiki.org/Tiki18结果
• 2018-11:https://doc.tiki.org/Tiki19
• 2019-6:https://doc.tiki.org/Tiki20

它的速度如此之快，以至于我们社区的一部分人喜欢使用结果版本！

公平地说，WordPress（文字出版社）在相同的大致时间段内，也有类似数量的主要发行版(https://wordpress.org/about/history/)但它的功能少得多。比Tiki最近，类型3和乔姆拉！已改为六个月的发布周期。但在所有这些情况下，使用基于扩展的模型，并不是所有功能都同时就绪。有时，扩展永远不会移植到下一个版本。多亏了Tiki模型，我们固有同步发布.

没有放缓的迹象等，即使开发确实放缓（因为功能成熟、开发人员减少或其他因素），每六个月仍会有一个新版本，尽管创新较少。

发布实际上变得更容易了，因为我们简化了流程，而且由于发布时间表，整个社区都是同步的。

开发人员越来越希望从事其他项目

如果代码库变得很难使用。有清理/重构项目很重要。

最好的解决方案是有合理时间表的客户资助项目。例如，客户需要一些新功能，并且在添加之前进行清理/重构更具成本效益，因此我们必须继续成为项目和顾问/网络商店。

关于我们离“棋盘的第二部分”还很远的争论

很多时候，国际象棋棋盘的类比被用来描述网络效应带来的使用量/销售额/价值的巨大增长。在这种情况下，系统的复杂性呈指数级增加，这一点得到了强调。

如果我们处于指数级的困难阶段，我们会看到

• 需要付出更多努力的改进；相反，事情变得越来越容易，因为我们重用了已经存在的代码，并利用了更好的组件（范围经济）
• 需要付出更多努力的发布；相反，我们的打包/发布基础设施正在变得越来越好（自动化程度越来越高）。

是的，但最终可能会发生

这真的很难争论，因为这是一件可以在未来的某个时候，没有人能够证明成功或失败，直到它发生。每年，一个营地都会说：“我早就告诉过你了”。另一个阵营说：“等等，它最终会来的。”

倾听担忧并采取相应行动很重要。也许这些警告实际上已经成为自我挫败的预言?

是什么让你认为社区不会适应？

Tiki模型在处理复杂性方面做得如何？

• PHP/MySQL/Zend Framework/Smarty/jQuery以及最近的Bootstrap和Vue.js是我们的基础，我们重用了大量代码。因此，这减少了我们的工作量。所有这些都在发展中（尤其是ZF2、Smarty3），所以我们的基础是尽可能防患于未然的。我们将大量工作转移到这些组件上，并通过重用它们提供的功能来避免新的工作。事实上，Tiki中提供的代码有一半以上来自外部库我们不需要维护（尽管有时我们需要帮助-当我们有一些修复时，我们会上游修复）。请参阅：源代码行.
• 多元化社区，包括商业生态系统
• 易于贡献
• 我们的狗粮现在真的很好。Tiki作为一个社区，依靠Tiki进行协作。例如：我们的bug跟踪器一开始不是很好，这是一个额外的工作负载（不仅是为了修复bug，还为了改进bug跟踪器）。但现在，Tiki作为一个应用程序是强大和成熟的。因此，我们的社区比功能/集成性较差或无法根据需要定制工具的社区效率更高（所有其他条件都相同）。
• 维基百科（Wikipedia）证明，“维基方式”（WikiWay）在处理复杂性方面确实很好。
• 很多人从来没有想过维基百科会像现在这么大。维基是数量和增长惊人的一个例子。它变得越来越大、越来越复杂，但随着人数的增加，他们可以解决更多的问题。维基百科需要支付巨大的服务器成本。在Tiki的案例中，即使将功能/开发人员/用户数量增加一倍，也不会造成重大财务风险。我们还需要一些专用服务器。除了Google Summer of Code之外，所有对Tiki的贡献都来自社区（通过咨询公司、IT部门等）。GSoC的贡献无疑使一些功能看起来比其他功能更快，但在引入后，它们是社区维护的，没有任何外部资金。
• 可维护性
  • 我们定期进行清理，例如，将功能推送到浏览器（例如：拼写检查器）。请参见：濒危特征
  • 我们失球了数据库独立性将重点放在MySQL上，以使事情更简单、更流畅。
• 可升级性
• 适应性
  • Tiki可以在不同版本之间进行重大更改，而不会放弃社区的一部分。重构的例子包括
    • Tiki3中的主题
    • Tiki3中的jQuery
    • Tiki4中的权限
    • Tiki5中的UTF-8处理
    • Tiki7中的跟踪器
    • Tiki8中的评论
    • Tiki13中的引导
    • Tiki的Vue.js 21
    • 托多：（这里将添加其他最近的重构示例）
• 尽早发布，经常发布
• 解释一下Clay Shirky，可解决的问题不是功能过载，而是更好的过滤器。
• 简介.tiki.org

一体式模型降低了复杂性

有些人认为核心中的所有代码增加了复杂性。那是因为他们只是在看核心。正常使用core+扩展应用程序必然意味着您将使用许多扩展。因此，您需要考虑这种实际使用。

现在，一体式代码库可以实现更多的核心重用、更少的重复、更多的代码审查，并避免依赖地狱。查看有关Tiki的更多信息模型.

风险在哪里，如何减轻风险？

• 活跃的Tiki社区成员非常清楚问题是
  • 需要定期进行重构和清理。
• 分支太多。裁判：生命周期
  • 分支越少越好
  • 翻译分支策略
• 新开发人员很难加入
  • 我们可以有更好的医生和更有组织的指导
  • 新员工涌入组织似乎并不会增加其软件的缺陷，可能是因为新员工一开始就有简单的任务。
• 快速发布时间表，“失去”社区的一部分。
  • 我们有LTS版本。请参见生命周期.
• 社区SWOT
  • SWOT分析

web应用程序变得越来越容易

软件总体上越来越好，期望值也越来越高。但总的来说，很明显，对于FLOSS web应用程序来说，事情一年比一年容易。

• 更好的整体生态系统（更好的浏览器、更快的JavaScript、HTML5、CSS3）使事情变得更容易。
• Git vs SVN vs CVS
• PHP8与PHP7、PHP5与PHP4、jQuery与手工编码JavaScript等。
  • 所有这些组件通常都具有良好的向后兼容性。
• 硬件更快，可以处理更多（摩尔定律）。
• 互联网连接更容易获得、更快、更可靠。
• 当我们2004年开始我们的电子表格，浏览器速度很慢，很难实现跨平台。最近的使用jQuery进行的修改是日夜对比.
• MapServer与GoogleMaps/OpenStreetMaps的对比是另一个例子，事情变得简单多了。
• 使用Bootstrap框架进行响应式web设计是jQuery手机+现代手机，在公园里散步与支持WAP手机相比.
• 几年前，我们尝试添加WebDAV支持。它起作用了，但速度太慢，几乎无法使用。现在，我们又回来了eZ Components的WebDAV实现
• UTF-8支持已不像2002年Tiki开始时那样！

那么现在呢？

剩余用例

如果我们看看用例,路线图、和缺少的功能很明显，与已经完成的工作相比，这只是一个小数字。这主要是我们真正擅长的。例如，添加时间表对Tiki来说折断骆驼背的稻草！

应该重申的是，Tiki（按原样）是目前内置功能最多的FLOSS web应用程序。它也是同类应用程序（Drupal、Joomla！、Plone、Typo3、TWiki等）中发布周期最快（如果不是最快的话）的之一。更多的功能吸引更多的人。有了足够的人员和协作，我们已经牢牢地掌握了Tiki面临的复杂性挑战。

Wiki套件

威尔WikiSuite（维基套件）把我们带到一个转折点，事情开始崩溃？这是一个合理的风险/顾虑，因为WikiSuite并非“完全相同”。它使Tiki社区走出了舒适区，并涉及

• 不同的社区
• 不同的存储库
• 不同的技术
• 不同的发展哲学
• 不同的发布时间表
• 等。

它还介绍了依赖性挑战蒂基到目前为止一直在回避的问题。

这就是说，每天都有SysAdmins/IT架构师在构建自己的“套件”并应对复杂性。他们主要是按组织执行此操作。他们可能会在这里或那里添加一些重新配置的胶水，但这基本上是没有社区和可持续性的个人倡议。

社区怎么会比这些不协调的倡议效率低呢？

建议的是联合此类人员的工作，并让项目本身进行协作。Tiki和BigBlueButton已经有了这种协作.Kaltura也是.

为了降低风险：

1选择正确的组件

• 为项目带来社区和经验。
• 它们处理自身的内部复杂性。
  • 我们并不是要求人们更改他们的客户端操作系统，因为所有客户端应用程序都是跨平台的。
• http://wikisuite.org/Component-criteria
• 尽可能使用相同的技术。
  • ClearOS是WikiSuite的选择，因为它是类似于Tiki的PHP/MySQL/jQuery，而不是Perl中的Zentyal。

2吸引眼球临界质量
正如一些Tiki社区成员遇到限制并需要ClearOS或Jitsi之类的东西一样，一些Jitsi社区成员也需要Tiki或ClearOS之类的东西。因此，由于组件的互补性，每个社区都有这些需求。而这些能量目前并没有以一种有组织的方式被管道化。

ClearOS报告118000个注册系统：大部分人会对互补功能感兴趣。

对于Tiki，我们没有系统注册，所以我们不知道安装了多少，只是安装了很多。大多数都在共享主机上，所以Suite无法访问（除非SaaS选项可用）。然而，即使是很小的一部分，也会有很多潜在用户

3严格支持的版本

为了减少依赖地狱，我们将对支持的版本号非常严格。我们可能会从遵循Tiki发布时间表开始，并使用当时可用的任何组件版本号。我们将努力让组件社区采用同步发布。接下来，我们将制作LTS版本。

4使用松耦合
http://en.wikipedia.org/wiki/Loose_coupling

5使用/推广开放标准

6在各自的组件项目中加入glueware（与在wikisuite.org上维护代码相比）

其他想法

• 如果有一张历史图表就好了。我怀疑这将表明新功能的数量正在放缓，我们的代码库复杂性也在控制之中。
  • 代码行
  • 首选选项数量
  • 活跃开发人员的数量（如Openhub.net）

相关链接

• https://joind.in/talk/view/3484
• http://www.shirky.com/weblog/2010/04-the-collapse-of-complex-businesss-models（http://www.shirky.com/weblog/2010/04-the-collapse-of-complex-businesses-models）/
• 模块化设计和复杂工件的开发：自由/开源软件的经验教训（2003）亚历山德罗·纳杜佐和亚历山德里·罗西
• http://css.csregistry.org/tiki-index.php？page=What%20are%20Complex%20Systems%20？
• 复杂性
• 关于复杂性的争论导致了Drupal分叉
• http://thenextweb.com/enterpreneur/2014/09/06/complexity-enterprises-bigest-debt/
• https://signalvnoise.com/the-majestic-monolith网站/

复杂性