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. 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 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. 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! Regards, Johannes -- 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. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
