mods.tiki.org

About Tiki Packages in Tiki 18.0 LTS and why I support this project. And mods.tiki.org can now be scheduled for retirement.

To the Tiki community,

Tiki 18.0 LTS has been recently released. It introduces a significant
new feature, and to a certain point, a change of paradigm. Please say
hello to Packages, a Web Installer for packages available from
Composer: https://doc.tiki.org/Packages

Thank you to Ricardo Melo and his team for having developed this great
feature, which required to first revamp how we use Composer in Tiki:
https://dev.tiki.org/Composer-Dependencies-Revamp

People who have been following Tiki for a while are aware that I am
very interested in software development models, and many times shared
my views with respect to (de)centralization of development and
deployment strategies, software life cycles and managing complexity.

Specifically, my thought about Tiki "Mods" when they were introduced
in October 2004: (yes, over 13 years ago!)
https://sourceforge.net/p/tikiwiki/mailman/message/13455128/

And I started this in 2008:
https://dev.tiki.org/To-Mods-Or-Not-To-Mods

More recently, I launched:
http://pluginproblems.com/

And now, here is an update on Tiki Mods: In recent times,
http://mods.tiki.org had only one active / useful mod left: PluginR
which "Allows using R syntax for statistics, scientific computing &
graphs (see http://www.r-project.org)."

It was added to Mods instead of the main code base to get around
licensing issues. Some of the code was derived from GPL code, and
thus, by letting users install themselves, they can accept the GPL
license (which is not 2-way compatible with Tiki's LGPL). More info
at: https://tiki.org/License

Thank you Jean-Marc Libs for rewriting the plugin and bundling it in
Tiki. Thus, mods can now be scheduled for retirement. And we can treat
that as a "Learning Experience". My conclusion is that if all the time
and energy (that was invested in Mods) had been invested in the
general Tiki code base and community sites, we'd be much better off
today.

So given my long-standing concerns with extensions / modules / Mods /
add-ons / plugins, it is a fair question to ask: why did I initiate
Packages? https://doc.tiki.org/Packages

What is the story?

1- It's more complicated than just being "for" or "against". If you
read carefully my previous messages about Mods, you'll see it's more
like "I think it's a good idea for this, but bad for that", and "it's
good if done in this way, but bad if done in this other way".

2- I strive to avoid wasting resources and painful failures (better to
fail fast and move on to something else). So when folks make plans
that are unrealistic (or have no plan), I try to warn them of the
pitfalls. It's a case of "I hope I am wrong and that you will succeed
but from what I see, you are headed for a wall".

Now, when someone tells me that my project is unlikely to succeed:
that doesn't mean that I just give up. But I do take the time to
listen and understand, and make sure I have a plan to overcome the
difficulties, and prove them wrong 😉.

3- I work and plan to avoid complexity and think in terms of long term
management efforts. It's easy to start / create stuff. The real
challenge is to build things sustainably, for the long term. So you
need to think of the ongoing time / effort it will require to maintain
something, and how the benefits of this "thing" will bring in
(attract) these resources.

The mods experiment didn't work out. But it's not just that some time
was "wasted" in an experiment, which happens all the time and is not
unhealthy. An additional concern is that some community members had to
invest time to clean up after:

• http://tikiwiki.1073613.n5.nabble.com/The-future-of-Mods-td18857.html
• http://tikiwiki.1073613.n5.nabble.com/The-state-of-mods-Cleanup-of-mods-where-are-we-going-with-this-tp8110p8112.html
• http://tikiwiki.1073613.n5.nabble.com/Moving-mods-goodies-to-main-codebase-especially-plugins-td16074.html

Even mose, who is one of the most important people in Tiki's history
(and who championed Mods) acknowledged that it was perhaps a mistake
(in retrospect)
https://tiki.org/Webinar-2012-10 (Go to minute 82)

Given these concerns, I'd like to explain how Packages are different,
and why they will succeed.
1- Provides benefits that can't be achieved in current system (ex.:
getting around disk size and license issues)
2- From day one, we planned for deployment. To make sure it would be
easy for people to use, the Web installer was the final goal, and
https://dev.tiki.org/Composer-Dependencies-Revamp was a prerequisite
3- The system doesn't encourage fragmentation of efforts
4- We are not just adding something. We are also removing something
(Mods). And thus, reducing that overhead on the long term. Will
require very little ongoing maintenance for the community (for site
management, releases, etc.) as it uses the existing composer.tiki.org
5- It leverages a robust / well tested system (Composer) and adds very
little complexity since Tiki has already been using Composer since
Tiki 11
6- We are managing libraries which are designed to be included in
diverse apps. The code in Tiki to use these libraries continues to be
managed in the main code base
7- We constrain in the GUI which library version will work with which
version of Tiki, limiting the number of things to test and keep
working
8- Next to no overhead for developers to use
9- The right type of people worked on the project so it's
well-thought-out, planned and executed. Jordi Boggiano, the lead
developer of Composer, reviewed our planned implementation and
confirmed it was OK.

As this infrastructure matures, I envisage that it will be extended to
other things like themes, fonts, image packs, etc. but as I did 13
years ago, I think that functionality / business logic should be
managed in the main Tiki code base.

We will provide a manual (FTP) way to install packages (not yet developed)

Best regards,

M 😉

--
Marc Laporte

http://WikiSuite.org
http://PluginProblems.com
http://Avan.Tech

TikiWiki-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tikiwiki-devel