[xwiki-devs] Back to the future of XWiki !

jstoldt j.stoldt at gmx.net
Tue Mar 8 23:39:22 UTC 2011

Hi everybody,

This is quite an interesting discussion for me. Before I comment on anything
of the before mentioned or come up with new points I would just like to
introduce me and my background a bit so you know where this is coming from.

I am a student of mechanical engineering with a keen interest on most
computer stuff and have done work in the Open Source community for a few
years now, although it was all focused on some C++ projects. During my
studies I did an internship in a rather large technical company which is
part of a globally active group. It was my task to build a knowledge
database for the employees of the department I worked for. In regards to
software I did research on different possible software alternatives (wiki,
CMS, Knowledge Management software) and finally picked one software product
with the help of cost-utility analysis. Also keep in mind that I had very
little experience with Java, servlets and other dynamic web software.

The major reasons for picking XWiki was the possibility to run it without
having to bother with buying a license, which can be quite a concern
depending on the complexity of the organization. Other reasons were the
support for importing office documents and having a custom build WYSIWYG
editor. Any corporate wiki that should contain data present before the
introduction of the wiki should probably allow importing office documents to
decrease the work on migration. Usability is also a major concern. Even in a
high-tech (not IT!) work environment many people have little or no
experience in using different IT tools so using the wiki should be as simple
as possible, which Office Import and the GWT WYSIWYG editor provide rather

Now, with the pretext I will turn to the discussion going on here. I think
the major problems XWiki has today is indeed the marketing. The technically
minded internet user will stumble over XWiki rather soon-ish but from my
experience in the above mentioned company I am convinced that the majority
of software integration projects are not actually done by the own
(outsourced) IT departments but by contractors. So in order to promote XWiki
it is mandatory to get more consulting firms to offer services for XWiki. In
Germany I found two consulting firms that actually offered XWiki support.
Support can also be a very crucial thing when using XWiki as a Knowledge
Database because usually the users are editing pages, at best. That means
somebody will have to update the software and such, which is preferably also
a contractor.

In the company I worked for there was a MS Sharepoint Server integration
project going on at the time. At some point we discussed the ongoing support
after my internship and we had a meeting with the contractor doing
Sharepoint. They did actually try to convince us to use Confluence because
they support it on the one hand and there is a possibility to link it with
Sharepoint on the other hand. These two arguments will probably make a lot
of potential customers opt for Confluence because this way they can minimize
their own trouble. So what can XWiki get out of this? XWiki should try to do
something just like that and preferably also with some of the major software
vendors. This way the acceptance among consultants will, IMO, rise and XWiki
has more points on the pro list. Admittedly, linking FOSS to proprietary
tools such as MS Office and MS Sharepoint does not sound too nice but for as
long as a reasonable percentage of the potential user base makes use of
those tools they should be included to some extent.

Another thing that bugged me a fair bit was creating and maintaining a
ready-to-use and productive environment. While the standalone package and
installer offer the user the possibility to have quick access to XWiki the
provided package do not replace a proper installation of a database and
servlet container. What I could imagine to be very useful to ease installing
a productive XWiki install for less advanced users would be to just make a
joint installer that will offer the user the ability to install and
configure, say, Tomcat 7 and postgreSQL 9 with XWiki. Next step would be to
provide a way to automate updates of the WAR container. Before I finished my
internship I actually wrote a script that copies necessary new files to a
newly extracted WAR container and overwrote a couple of default settings
with the custom settings I picked. Also, updating the XAR contents is always
a bit of a stretch to someone who has little idea of how the system is
configured. IMO there needs to be a way that will not overwrite
customizations all the time. This works reasonably well for themes by just
creating a copying the default theme and using the renamed copy instead
because that one will not be overwritten, not such luck for other files,
however. To sum this up, the bar for installing and updating XWiki/XE should
be lowered for less techy/computery users.

I already mentioned the installing and updating process in general but the
next thing that pops into my head was when I had to make the transition from
postgreSQL to MS SQL Server due to the requirements made by the IT
departments. Namely, they only supported MS SQL and Oracle. However, much
unlike for postgreSQL I had to add the MS SQL hibernate settings from
scratch and I also needed to add some special XML to the /WEB-INF/classes/
directory (IIRC). All this was reasonably well documented, but IMO it still
poses as a "paper cut" and there is certainly room for improvement.

In regards to support I would like to second Andreas' opinion, IMO a
bulletin board of some sort is better. I am still not really comfortable
using mailing lists, even though I do use them just now via nabble. It is
probably just a bad habit of mine to stick to support boards and mailing
lists are somehow "very Open Source" but then, support from the community
should be available with minimum effort to promote the software. On the very
bright side, however, I love the IIRC channel, which is usually a great
place to go for quick and friendly support, so that really deserves a

Another thing that is not worthy is the focus on the targeted audience. Much
unlike in my own projects I approached XWiki from a user point of view and
while I could rely on my coding background and other computer related
knowledge I couldn't help noticing a variety of paper cuts which might not
appear as such to the developer. I know this is very hard to do but
developers should try to view their product more like users do every once in
a while. This is probably the hardest task because it is incredibly hard to
play the first time user with little computer/web experience when you are
not, still, I think this can be very beneficial.

Well, I figure I have run dry for now. Anyway, I hope I could give you some
impulses. Keep up the great work!


View this message in context: http://xwiki.475771.n2.nabble.com/Back-to-the-future-of-XWiki-tp6084764p6151364.html
Sent from the XWiki- Dev mailing list archive at Nabble.com.

More information about the devs mailing list