Hi,

(Sorry for such a long message, but I hope you'll find it interesting)

I've started using Piwigo this summer. Currently, I'm using the piwigo.com hosting service (http://mmoy.piwigo.com). I started as a basic user, picking a theme and a handfull of plugins. Then I started having fun configuring my gallery and hacking the CSS. Then I decided to take the plunge and checkout Piwigo from SVN and start submitting patches.

Following is a feedback on my experience, but before this, a few words about myself. I've been a free software enthusiast for almost 15 years, and while I have limited time to spend on it, I could contribute to various pieces of software. These days, I'm most involved in the Git community. I have a bit of experience in PHP/web development, but I'm far from being a specialist.

Many of you speak french. If so, you can read http://linuxfr.org/news/piwigo-2-7-un-c … vos-photos to get an idea of the reasons I chose Piwigo. In short: flexibility, sustainability and to some extent the business model (the fact that there's a company behind increases my trust in the sustainability, and the fact that the company is ethically compatible with my ideas is cool).

Still, Piwigo has been source of frustration for many reasons. I'm afraid my feedback will insist more on the negative points than the positive ones, but don't get me wrong: I write such criticism because I think Piwigo can evolve and is not so far from what I would expect it to be. As a proof of my good faith, I sent a few patches before writing this ;-).

As a beginner, I found it difficult to find a theme that was visually pleasing with my criteria. One of them is that I want the focus on the pictures, not the web page around it. Many themes succeed in removing useless and disturbing elements around the picture, but by default, almost all of them use a fixed-size image. I have a 16Mpx camera, with which I try to take sharp and nice pictures, a 3.6Mpx screen, and most themes use less than 0.5Mpx (not even 15% of my pixels) to display the image. Then I discovered the Automatic Size plugin. Much better, but unfortunately it's incompatible with many themes. The "stripped" family of themes look really good on small displays, but even "stripped responsive" fails to be actually responsive on large screens. The maximum width is 1140 pixels wide (i.e. a bit less than half of my screen). I picked the Modus theme essentially because it was the one best at filling-in my screen with the picture. Fortunately, I do like the look of Modus. Great work, and actually responsive design from my mobile phone to my large screen. But I think it ruins the point of having themes when we're forced to select one and only one theme based on one feature.

Honestly, I first gave up with Piwigo, and wouldn't have come back if Pierrick hadn't convinced me.

Then, I started playing with more advanced features. Indeed, I was surprised to find how flexible Piwigo is (for example, the fact that even piwigo.com allows me to edit my CSS and inject HTML or CSS anywhere in my gallery is great).

I also started finding bugs. I may be unlucky, but I don't remember having reported so many bugs in such a short period of time. One of the bugs have been fixed, but others are waiting patiently for someone to fix them. Take for example [Bugtracker] ticket 3118. I did the hard work, found the origin of the problem, suggested a two-lines fix (a <div id="the_page"> and a </div>) back in August. Nobody bothered to actually write and commit these two lines of code. Well, now, I did. We'll see how long my patch takes before being committed. For a piece of software that calls itself "mature", I find the bug density very disappointing. A common complain against free software is that it takes its users for beta-testers, and Piwigo does not really contradict this.

For someone used to Git, pull-requests and mailing-lists, contributing to an SVN repository and using Mantis was not such a pleasant experience. I fixed a typo in a string, it took me around 10 minutes to submit the patch, and it will take almost as much for someone else to apply it, not even sure it was worth it. Pierrick told me that you were considering a migration to github. Indeed, don't underestimate the benefit of using a system where anyone can get a clone and send pull requests to lower the cost for occasional contributors. I can argue more about the benefits of Git over SVN if you want ;-). (And I can help with the migration). I guess the best for now would be for me to get an SVN access. But for most of my contributions, I'm not familiar enough with the code and I do appreciate to get a review before my code gets to the main repo. I don't know what the common practice is here, but clearly SVN does not help.

I appreciate the fact that Piwigo is extensible through plugins, but I do not understand why the community insists in keeping many important features out of the core. A common argument in favor of plugins is that it keeps the code well structured. I do not agree, and I think this is coming from a confusion between modular design and plugin systems. Take the Linux kernel for example. Of course, everybody is happy that there's no dependency between the driver of my graphic card and the one of my network interface. Still, all drivers are maintained together in a consistent and modular codebase. Pushing too many features in plugins, on the other hand, fragments the codebase, the development team and the user interface. It decreases the quality of the overall software.

As I said, I disagree that a plugin system helps having a modular codebase. No one needs a plugin system to have weakly coupled modules, but on the other hand, there are semantic dependencies between features. The plugin system does not solves them, but just hides them. For example, the Modus theme comes with its own icon set. The User Collection plugin adds a button with an icon not in the default set. At some point, someone has to decide what this button should look like in the Modus theme. I proposed a patch doing this in the Modus theme, but it's not really satisfactory to talk about a particular plugin in a particular theme. We could do the opposite, and have the User Collection plugin tell how the button should look like using Modus. The plugin system does not solve anything. On the other hand, if User Collection was a feature of the core (not necessarily activated by default), the problem would not be there.

Actually, in a well-structured and modular codebase, themes would only change the appearance of galleries. In practice, since it seems easier to contribute to themes than to the core, people tend to add features that should belong to the core in themes. Modus implements a nice size-choosing algorithm to adapt the size of the image to the screen. Stripped implements image preloads. In both cases, I'm happy that the features are there, but I'd be much happier if contributors had been encouraged to contribute this to the core, so that other themes could use it.

The plugin system also fragments the development team. Instead of encouraging potential contributors to contribute to the same codebase and work together, it encourages people to work by their own. A detail, but on http://piwigo.org/ext/, each extension has an "author" field, and "author" is singular here. How do you do code review alone? What happens to the feature the day the author abandons it? Ever heard of "collective code ownership"?

A direct consequence is that when someone wants to add something to a plugin or theme, the common practice seems to be to fork it. So, instead of having one "MontBlanc" theme with a tickbox "negative colors" in its configuration, I have two themes, "MontBlanc XL" and "BlancMont XL" by two different authors. This results in code duplication hence bad maintainability, and also messes up things from the user point of view: it would be much easier to chose from a reduced set of themes having the same functionality if duplicates were eliminated.

Plugins are somehow considered as second-zone citizens from the quality point of view. The core benefits from a beta-testing period, release-candidates, and is released only after some tests. OTOH, plugins are released "free style", I never saw any testing period before a release, but I do remember a release with a PHP syntax error in it. And I do not understand the reason why the core's release is decoupled from the plugin's update. For example, the release announcement for 2.7 presents new features very nicely, but forgets to mention "don't upgrade now if you use plugins, it would break your gallery". No surprise, we saw many users having issues with this on the forum right after the release. As a user, when a new release is done, I'd expect to be able to use it right away.

And finally, I do not buy the argument that the plugin system simplifies the user-interface. First, some plugins are really useful, and I do not see a reason to have them disabled by default. For example, "Admin tools" is great, and administrating a Piwigo gallery without it is a pain. Why let user experience this pain before they discover it? What is the benefit of having it disabled by default? Then, "Extended Description". Not useful to everyone, I agree, but is it harmful for anyone? The plugin does not add anything to the administration GUI except documentation. The feature itself could exist for everyone without being used, and without disturbing the user. On the other hand, this is one more example of semantic dependency between plugins, as the "Additional Pages" plugin provides a skeleton page that uses the "Extended description" syntax. As a user, I saw this, did not understand, spend a while investigating, reported this as a bug ([Bugtracker] ticket 3116), got no reply, and eventually found out later. Having "Extended Description" in the core would have saved me around an hour searching for the feature. I already mentioned "Automatic Size". I do not understand why it needs to take more than one check-box in the interface, in Configuration -> Option -> Photo size, and why it is disabled by default (have you seen anyone complaining that Google+ or Flickr automatically resizes pictures?).

Still from the user-interface point of view, the core is well-organized, the sidebar contains sections (Pictures, albums, users, ...) and subsections, one usually finds the right item at the right place. When it comes to plugins, OTOH, we get a bulk, flat list. First, a flat list to chose from when installing the plugin, and then in daily use, a flat list below the "plugins" section. Some plugins change the appearance of the gallery, and would deserve an entry in near the "themes" subsection, other allow better statistics and would be expected near the "history" subsection, and so on. But the plugin system breaks the organization of the administration interface and considers everything flat.

Unfortunately, not only the list is flat, but plugin names are often not meaningful for the user. Many of them are named after the technology they use (remember the time when Piwigo was named "PHP Web Gallery"?). I was looking for a slideshow plugin. I looked for 'slide', 'show', 'screen', 'full', none matched (matching on the description in the search box of the plugin install tab would already be a good step forward). Then, I found Fotorama, named after the JavaScript library it uses. The worst name is probably "PWG Stuffs". I learned what PWG meant long after I discovered the plugin, and "Stuffs", really? (BTW, the plugin itself is great, even though the name is meaningless) (and BTW, I have plans for it, it may become even greater soon ;-) ).

Don't get me wrong, I'm not arguing that the plugin system in itself is bad. It is great to have it for cases where the feature could disturb users (I can imagine people complaining about LocalFiles editor being too complex for them for example), and it is good that some users can write their own plugins for their own needs. The problem for me is not to have code in plugins, but to encourage people to write important features in themes and plugins.

OK, I do realize that my "feedback" contains far more negative aspects than positive ones. But again, all this is meant to be constructive. Part of my frustration comes from the fact that Piwigo is a good program (otherwise, I'd have given up long ago ;-) ). I'm a happy user now because I think the drawbacks of Piwigo are compensated by the freedom it offers. I'm hoping that I will soon be able to prefer Piwigo to the proprietary alternatives even from a purely technical point of view. And I even hope that I'll be able to help as an occasional contributor.

Cheers,

Last edited by mmoy (2014-10-05 21:00:56)