Hi Vincent, Regarding the download page, this looks like really nice progress. Listing consulting firms there is also a nice and handy approach. Not listing non-contributing firms is a very legit and understandable thing from a development community POV. However, I was actually not pointing at how it is hard to find supporting firms, I was much more pointing at how few there are around and how many support Confluence. What XWiki should try, one way or another, is to make more companies support XWiki. The major problems here are that many consulting firms do not have a lot of man-power so they have to focus on a smaller portfolio to keep up with the work load. Also, it is self-explanatory that more consultants and consulting firm will cause the market to be a lot more competitive. Still, I believe that if more support is available more customers will use it, more feedback and requests will be generated toward those consultants and, hopefully, they will actually start contributing in public.
About the whole VM business, I understand that this is getting ever more important these days but I am not a real fan of the ready to go VM. I considered this in my internship for another software I looked into and then figured out the only two ways to run the VM was to use either a commercial version of some VM software or to go with the VMWare Player which didn't really sound appropriate for production either. In the end I installed XWiki on a virtual instance of MS Windows Server 2008 R2 with a MS SQL Server 2008 R2 database within the cloud of the IT company that manages the whole IT business for the company. This setup would at least only require the web server/servlet container and XWiki WAR to be maintained from somebody other than the IT folks. The point being that VMs are nice in a small environment where the structures are small and clear or even just local. But as soon as it goes into larger business there is bound to be more trouble than just upload and run a pre-built VM. You are right that you need feedback from technical users on what configurations and so forth and I tried giving and adding such information over the past few months. However, my point was that it should simply be easier to use. I discussed this with Caleb last night and he had this idea about some sort of wizard which sounds like exactly the thing I was thinking about. Collect the necessary information on configurations and such from the user and build it into a tiny tool that helps configuring a ready-to-use productive environment. The Extension Manager sounds really nice and I believe you will be able to make great things happen with it. Still, this seems to be more of a top level back-end framework that will ease integration with other software, features and so forth. What I was talking about, however, was that XWiki could greatly benefit from working more closely with other de facto company standards. I already mentioned MS Sharepoint Server integration, although admittedly, I never got around checking out what Atlassian offers there in detail. Another thing I could think of would be to use XWiki somehow more closely along with Lotus Notes. For instance, my former company had some workflows which were spread among SAP and Lotus Notes and I believe there are use cases where an integration with XWiki would be benefitial, like reusing data stored in a Lotus Notes database and view it in a nicer fashion in XWiki. IMO a lot of engineering and design departments can make great use of wiki software in general but what they need even more nowadays is a Product Data Management system. So why not see if there are ways to integrate XWiki in PTC Windchill, Dassault Systemes ENOVIA, SAP PLM or Siemens PLM Software? This is obviously very technical with a very focused market but I believe these could be great selling points, especially if patronages or collaborations with some of the major PDM/PLM vendors can be established. About updating, what I would really love to see would be sort of update packages. I know this will increase the workload for the release manager but I think creating minimal packages that only update necessities in an automated fashion will lower the threshold for people being comfortable with updating even if they have little idea of what they are doing. Also, a stricter separation between setting storage pages and code pages would be neat. I do not know if this is possible but what I could imagine to be great would be to stop shipping documents like WebPreferences or XWikiPreferences and instead make code documents that will automatically create those documents with defaulted settings (like they are now in the shipped documents) from code if they do not already exist. It would also be neat to have settings like "hide full email address" not in the code file but in a central place so it will not be overwritten accidentally. In general, I think it would help to have configurable "hard settings" in extra properties and on upgrade check if the value was manually set. If they are set they are ignored and not overwritten, if they are not set just use the default defined in the code. One example for that, the recently modified panel shows only 5 entries, I preferred to show 10, so it would be neat to just have a property in the document that is empty on shipment. When a user views the panel the code checks the property and if it is empty it uses the default 5 otherwise it uses the value provided in the property (e.g. 10). Regarding the paper cuts, I report some of those I found on JIRA and/or the IRC channel but since I am no longer anywhere near a productive environment and I know my way around the system it is getting harder for me to spot them as such... it is just like what I described, I don't think like the default user anymore. Anyway, one of the bigger one that pop into my head just now is that I remember a colleague having trouble using the Office Import in the WYSIWYG editor for large documents could result in errors. Sometimes I could not delete pages until I restarted Tomcat. The WYSIWYG editor does not alway give the result which I would consider more suitable at that point (e.g. color background in a table does not color the cells background but the text background. I know that is correct from HTML POV but for an office user, I think, the cell would make more sense) or does not even allow certain style manipulations (e.g. vertical alignment or merging of cells, JIRA on that exists already). Thanks for working through my lengthy mess, yet again, Johannes :-D -- View this message in context: http://xwiki.475771.n2.nabble.com/Back-to-the-future-of-XWiki-tp6084764p6153047.html Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
