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

Vincent Massol vincent at massol.net
Wed Mar 9 07:43:58 UTC 2011

Hi Johannes,

Let me try to list below the initiatives we've started to address the valid concerns you've raised.

On Mar 9, 2011, at 12:39 AM, jstoldt wrote:

> 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
> well.
> 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.

We've started to address this with the new download page which lists companies offering support for XWiki. We only wanted to list companies participating to the xwiki development though. Maybe we'll revisit this rule later and allow listing companies not participating to the xwiki development (although I don't like very much the notion of people benefitting from XWiki without giving back something).
This download page is going to be active in the coming few days. To try it go to http://enterprise.xwiki.org/xwiki/bin/view/Main/Download and click on the download link.

I know it's a small start but it goes in the direction you mentioned.

Also remember that we're talking about xwiki.org here and not XWiki SAS. While XWiki SAS can have partners (and it has!), it's different for xwiki.org. The best xwiki.org can do is:
* implement business integration (but that's costly to do and very few open source committers will do it - usually it's done by companies sponsoring the development of it)
* list companies providing support - started

> 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.

Several answers here:

* We've started developing an Extension Manager. A first version is available in XE 3.0 final and we'll continue it in 3.1 and beyond. Its goal is to make it easy to install/upgrade/manage extensions (applications, macros, etc).
* XWiki SAS wants to provide some already made VMs with all installed stuff (DB, app server, admin tools, etc) in the future. Of course if someone in the community wants to do that, he's free to do it but it's a lot of work to create and maintain (and thus costs a lot).
* Since xwiki developers themselves can't know all OS/DBs/app servers, it's the role of tech-savvy users to contribute back their settings on xwiki.org or in the form of packagers IMO.

> 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.

Again this for tech users to contribute back to the documentation of this IMO.

> 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
> compliment!
> 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.

Would be great if you list them to check if we have them in mind or not.

> 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 know we're all trying hard to do this. We have even recruited Ecaterina as a designer/usability expert to help us on this.

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

Great feedback that matches my own view of what we need to do, especially on the upgradability part.


> Regards,
> Johannes

More information about the devs mailing list