Tiki is already one of the most feature-rich social business/web content management platforms that exist today, with all of these features being shipped in an "all-in-one" package, which makes it all the more impressive. Throughout its history, hundreds of developers have contributed directly to its co
Nevertheless, in Tiki 14, the Tiki Addons feature was added to allow a way for thousands of developers to add an even broader range of functionality that can be used with Tiki. Addons are not to be confused with Mods which is an old feature that has more limited uses. In the longer run, there is a possibility Addons might completely replace Mods, even though right now Mods are still simpler if you simply want to include say, a wiki-plugin that can't be committed to the main Tiki co
One of the most powerful features of Tiki Addons is that it allows deploying a combination of PHP code, Smarty Templates, Preferences, as well as Profiles in one package. This allows for an unlimited range of tracker based applications that also make use of other Tiki features to be deployed. Although Profiles adequately provided a means to deliver sets of initial configurations for a Tiki installation, and provided lots of examples of possible configuration possibilities, it lacked the means to deploy them in a versioned and managed way together with custom templates and prefs. Tiki Addons addresses these limitations and transforms Tiki into a full-fledged application framework.
One of Tiki's core strengths is the fact that it has an all-in-one model that reduces duplication and encourages collaboration amongst community members. Theoretically, it should lead to better software and a more integrated approach at solving problems.
However, there are times where it is justified and beneficial for the Tiki Community as a whole, to allow for code that exists outside of the main Tiki co
The conditions that support the development of an Addon instead of committing directly to the Tiki co
- Something should be an add-on if one envisages at least (approx.) 50 variants of it as beneficial to have. The advantage of using Addons instead of it being in the main Tiki co
debase is the ability for different developers working in different industry verticals or environments to develop variants of the same functionality but for different markets. Some examples of suitable addons:
- Custom Activity Streams implementations
- Advanced PluginCustomSearch implementations
- Organic Groups implementations
- E-commerce/Shopping Cart implementations
- CRM (customer/constituent relationship management) implementations
- ERP (enterprise resource planning) implementations
- Project management applications
- Social Networking applications
- Integrations with 3rd party applications, e.g. as used in Tiki Suite (Note that integrations with some key open source software should be in the main Tiki co
debase but of course it will be impossible to have them all there).
- The complexity of maintaining such "applications" or "implementations" in the main Tiki co
debase introduces a level of complexity that is really difficult to manage.For example, it might lead to unrealistic proliferation of feature Preferences. It might make it impossible to further improve the feature without affecting how it currently works. Or it might make it really difficult for other developers to Respect Environment, one of the 3 Rules of development in the Tiki community. In these cases, developing the new functionality as an Addon is justified.
- Correct tools must be used to support effective collaboration in the development of Addons. The needs for effective collaborative development of distributed addons are different from what is needed for the development of an "all-in-one" Tiki co
debase. For example, the revision control management system for Addons is GIT (instead of SVN) and addon developers are strongly encouraged to make available their addons as a GITHUB repo. For a clearer explanation on why distributed systems collaborate in a different way and therefore need Distributed revision control, see Distributed revision control.
- Addons must only interface with the main Tiki co
debase via a published API,and *not* in any adhoc way. Addon developers must not call general Tiki functions directly but instead make only published Addon API calls. This makes sure that as Tiki's main co debase continues to evolve, that Addons are not perpetually broken (since Tiki's "Respect Environment" rule does not extend to ensuring that an infinite number of Addons do not break, the only exception being the responsibility to respect the published Addons API). If an Addon developer finds that something is missing in the Addons API that they need for what they are developing, they are to be encouraged to improve the Addons API in the main Tiki co debase.
- When functionality that is being developed for an addon is useful in a generic way to other addons, it should be done as an improvement to the Addons API, rather than in individual addons. As such, one of the steps in the checklist provided to addon developers is to ask oneself if there is functionality that should be in the Addons API rather than inside the individual Addon.
- You are on the right track if your addons is more about profiles and templates than it is about code. Because that means you are leveraging Tiki core functionality.
The following are not good reasons for developing an AddOn instead of contributing directly to the Tiki co
- To avoid communicating with other Tiki developers to collaborate on the new feature because of laziness or otherwise (why would you want to do this any way since we are such a nice bunch )
- Unwillingness to find out if a feature exists already (and if it can be improved on) before building it from scratch. This goes against the philosophy of participating in the Tiki Community in an integrated, open and transparent way, the wiki way. It hurts the Community in the longer run by creating unnecessary silos.
Nevertheless, regardless of the guidelines above, at times, developers may be constrained legally or otherwise by their customers, funders or employers in contributing the new functionality into the main Tiki co
While the Tiki Community strongly encourage developers and consultants to educate their customers, funders or employers on the benefits of participating in as integrated a fashion as possible in open source communities, at times true constraints do exist. In such situations in the past, developers have typically "forked" the main Tiki code base into a private branch, and improvements are not contributed to the Tiki Community anyway. Moreover, the "forked" version of Tiki becomes harder to upgrade and more costly to maintain.
In such situations, developers will find that it makes much more sense to develop the functionality as a Tiki Addon rather than directly in a "forked version" of the Tiki co
It will also be easier to convince customers/funders/employers to pay for the contribution of more generic parts of the new development as improvements to the Tiki Addons API in the main Tiki co
Also, in some cases there is actually a desire to share back the new functionality but the code is in a state of being "too custom" to be committed directly into the main Tiki co
|Rating||Subject||Submitted by||Importance||Easy to solve?||Priority||Category||Volunteered to solve||LastModif||Comments|
|(1)||Organic Group Addon gone in current 14.x compared to what doc.t.o says about it||Xavier de Pedro||8||5||40||2015-04-23||1|
koth-29 Apr 16
|(0)||LIST results not visible for Anonymous||Torsten Fabricius||10 high||0||2016-12-02||4|
Bsfez-14 Feb 17
|(0)||"https://getcomposer.org/versions" file could not be downloaded:||ShowCaseSupport@projectashenfire.org||6||0||2019-04-12||0|