Hi Pavel,

Any open source project potentially suffers from the lack of dedicated resources. Solutions seem to be that the project delivers such a high utility that people are attracted/willing to assist, but I doubt an asset management (AM) system falls into this category. The other option is a paid-for support model, like Red Hat, where the software is open source but the configuration, deployment, and on-going assistance is commercial. I'd suggest that GLPI has scope for this. Any commercial work has to fold back into the open source core, but AM/CMDB is a necessary requirement for an IT team of any reasonable size, so there is definitely a global market. Plug-ins can be similarly supported in this commercial model, even if the code is open source.

However, having worked for an EAMS vendor, my observation is that GLPI is still engineered as a 'development installation', not a 'configuration installation'. That is, to tailor the system beyond anything trivial needs to be done in-the-code, rather than via parameters or with a GUI designer. That's actually a seriously limiting factor in adoption, because it's making the documentation - at every level - more important than it otherwise might be. People are happy to play around with open source, to a certain extent, because it has no license cost so there is no real risk if it does not work out. But if a savvy non-developer IT user can't tweak it without opening the hood and changing code, well then they tend to move on. There are way more configurators than developers, after all.

I'm not sure how that assists the GLPI team, but having looked at the Product Roadmap, it's not obvious that fundamental changes are planned to position GLPI as a competitive platform, rather than interesting but not-compelling software. Anyway, I'm not sure my musings help, but irrespective, I'm certainly glad I found GLPI because it's helping in a project and the only investment has been my time to (somewhat) work it all out.

Regards,

Tghu

Also, small things like the Discussion Forum requiring a delay between searches make GLPI seem very amateurish. It really limits how quickly you can determine whether a question can be answered and the 30 second delay makes it more likely potential users will move along to something else. It's just so old-school:

"Info

At least 30 seconds have to pass between searches. Please wait 14 seconds and try searching again."

The site needs HTTPS to secure it.

One no-cost SSL Cert possibility is the EFF's Certbot, deploying 'Let's Encrypt; certificates (https://certbot.eff.org/). Their certs are simple to configure and install on open source web platforms, and support automatic renewal so are very low maintenance.

Hey Pavel, totally agree.

I'm creating a localized en-GB.po for a project and finding those little "not quite right" English niggles that you mention. But it's not always obvious whether a term has been incorrectly translated, or is supposed to be that way. For example, I expect that the recurring "Dictionnary" word (e.g., "Dictionnary of computer models") really should be "Dictionary", but as I've not yet come across the label in application use, I'm not making a change.

But the bigger issue is the documentation. The English version seems only about half completed before it collapses back into French (at least, I think it's French). GLPI is not overly complicated to use, but without user guides and admin manuals, the barrier to learning is too high, and potential users give up and move on.

Regards,

Tghu