Hi Andreas, everyone On Fri, Mar 4, 2011 at 10:48 AM, Andreas Hahn <ahahn(a)gmx.net> wrote: "confluence" is a word of the English language, it makes this chart off by far. This one would be a bit more relevant in my opinion : http://www.google.com/trends?q=xwiki%2C+atlassian%2C+mindtouch& but I still don't think it means that much. Ludovic will probably answer this for himself, but as a quick remark I think you've misinterpreted his mail. He doesn't say he will come back as a developer, but only as a Product Marketing lead, thus working close to developers and the community, because, well, that's how (real) open source software is developed. I think this vision is not complete. Cloud and hosted software got a lot of attention lately, but in-house software is not dead yet. Maybe in a couple of years in-house will mean "deployed on a private cloud", but we are still far from here, we would have first to see a complete, mature, open source cloud solution emerge, and have organizations deploy it on their infrastructures. I think we are speaking of half a decade here, so we have time to try and not miss that train :) In the mean time, I think XWiki's greatest challenge is to become the de-facto standard in the enterprise open source stack when speaking collaboration. Right now we are not badly positioned when speaking of "collaborative edition/redaction". We need to affirm this position and push it further to "collaboration" in a larger meaning (without trying to be the solution to everything or a social network tool, because that's not what XWiki is). Now I agree with you, it would be of course a good thing to have the EC2 distribution, the VMWare images and be present in more online offerings etc. Just I think it's not absolutely critical versus making XWiki a product so great that it just becomes a logical choice for collaboration. I also agree having easy installs on linux would be great to increase visibility. But as a I understand, the cost of packing java apps for linux is quite high. This is why you don't see packages even for popular java (web) applications. Trying to replace all blogs out there by XWiki is not going to help too much IMHO. Even if we geeks like it to use our toy for absolutely everything, for the rest of the world, XWiki remains mainly a professional software for doing collaborative edition. That was my 2 cents. Not trying to just "defend my turf" as one of the developer of XWiki, but rather trying to balance the vision that says we need to be very strong on the web / commercial clouds to win. There already have been some success stories of open source end-user applications (in the sense: not infrastructure apps) a la Alfresco, Liferay, Zimbra, etc. I think XWiki is a candidate for such, even if we are not there yet. The important part in my opinion is building a great product, the rest will come naturally. That's why having strong product marketing with Ludovic being active on features investigation and design make sense and will be a good thing in my opinion. Jerome.

On Fri, Mar 4, 2011 at 14:58, Vincent Massol <vincent(a)massol.net> wrote: I agree fully. * have xwiki talks at more conferences (by xwiki devs and by users) I have already think about that, but development is moving so quickly that this is a big change to covers all recents features... My very big +1 on this point. Currently, the most important feedback from our customers says that they feel the product to be too much complex and are afraid by having so much choice in the interface. We have try to mitigate that by adding our own "interface hiding" feature, trying to remove as much as possible, and not show what you have no rights for or is not active. As you can imagine, this is the opposite of adding features. To be even more concrete, let me take the last request I have received. It was about having a single "Connexion" links in place of having "Register" and "Identification". My customer was saying: "how can you live without what all other sites have, a single login form that allows to register when you do not have an account ?" I know changing this is not so difficult, but it should be built-in IMO. You can't imagine how much support we do just about login, lost password, etc... As another example, I was trying to made a very minimalistic interface for a very small group of non-technicians that would like to share some ideas. Having a full wiki just for them is overkill, so I made a space. But without changing .vm, its is almost not possible to have a simple interface (even with our hiding feature). I hate changing vm since it is a pain to maintain the changes over releases. After an hour of work, I finally just left of due to the top left search box that was not working properly (it was a 2.4, I had to fix a {html} issue, of course I know some changes may have been done since then, but anyway...). Basically, when you search in the search box, you leave the current space, which may cause skin changes (terrible for an end-user accessing only a single space), and search results shows a listbox of all spaces, while you may only access a few. We had finally use Google Docs :( I regrets not to have much time now to works on these simple interface issues that could be a real barrier for basic users. I really encourage any developments that improve remaining legacy code or that contribute to simplifying or clarifying the interface. Cathy do a great job at this, but implementation does not always follows. If I would have time, I would have focus my time on simplifying, and having an interface for basic and advanced users more separated, allowing to show features only if requested. XWiki is now a big piece of software, we should be careful not to afraid users with overwhelming features, and ensure that basic and already existing features are fully featured but simple. Of course, I agree that I am not being of much help currently :( Denis -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

Hi Ludovic, thanks a lot for your comprehensive response. The motivation of my response to the thread you have initiated was to get better feelings about the ongoing continuity and the direction of the xwiki product. First of all I'd like to better understand the relation between XWiki SAS and the XWiki community. As I see it more than 90% percent of the regular committers are employees of XWiki SAS. This means the vitality of the Xwiki OpenSource directly depends on the health of XWiki SAS. You might think this shouldn't bother users as this is free software. Now after 30 years in IT-industry I have seen quite some products rise and fall and in 2 cases have suffered from that. So the financial background of a supplier - or understanding its business model - is a natural interest for me when beginning to spend time and resources on it. Looking at the public material on the homepage of xwiki.com, xwiki.org the discussions on the boards their focus and priorities the testimonials and claims I doubt that there is a positive cashflow of revenues somehow related to the Xwiki software. Reading between the lines of your postings it seems that also vision has got lost somehow. I don't mean to be offending - I just try to understand the motivation and/or business model behind it to get a better feeling about the risk of this project being discontinued suddenly. So far its my impression that the project is financed by some sort of generous patronage - maybe like Mark Shuttleworth of Canoncial who became a happy and generous sponsor of Ubuntu Linux after selling his startup. I'd be happy to hear your comment on that ;) Now for the targets. a) If (in contrast to the above) there is a need to make some (more) money in a reasonable timeframe I'd go and copycat the atlassian way. AFAIK they are joining forces with some industry heavy weights. I think I remember having read about SAP selling confluence licences and services as a complemantary offer to SAP's existing user base. No surprise that atlassian claims having almost 10.000 installations. If you are interested in this topic I'd write more about what opportunities I can imagine here and what steps can be taken. Of course - developing a business like this is nothing that developers could do as a side job. b) Succeeding as OpenSource simply by the quality of the software looks far more complicated to me. Blogging software, CMS, wikis - they all are competing for the attention of publishers and there is quite some overlap in functionality - if not in the end they all will be the same. As long as XWiki is not installed by webhosters it means that users have to install the service of their own. Only companies with IT-department and people with IT background can do that which is a severe reduction of the potential user base. But bringing 'collaboration' software to companies is more than a technical issue. Management is involved as it needs to be confident that their companies knowledge is not being shared with the wrong people. You need to build a reputation first to get there - or you are joining forces with other companies that already know the customer and have that reputation see a) Atlassian/SAP - this seems to be far more easy than b) to me. Beside all the mentioned features - I think an (the most) important one has not even been mentioned. Simplify individual design of wiki pages. For example by making it sort of compatible with page layout software like Artisteer. I have been mentioning it a couple of times and I know I'm getting boring now so please read my old postings on it. Its *not* a solution to extend the presentation admin form to support more options. Besides - I think that there are also some other simple things that help better promoting the software - - doing a video like this one http://www.atlassian.com/software/confluence/videos/overview.jsp - reconsider communication with users through a more widely recognized media instead of the mailing list (for example stackoverflow.com) I'd be interested in ongoing discussion on all of this but please understand it might take a while until i find the time to respond. Andreas Am 04.03.2011 21:27, schrieb Ludovic Dubost:

Hi Andreas, Le 06/03/11 23:29, Andreas Hahn a écrit : get better feelings about the ongoing continuity and the direction of the xwiki product. SAS and the XWiki community. employees of XWiki SAS. This is right. Now not all committers are as tied to XWiki SAS than it might seem. Most of our committers are more tied to the XWiki Open Source product than they are tied to XWiki SAS. the health of XWiki SAS. You might think this shouldn't bother users as this is free software. rise and fall. So the financial background of a supplier - or understanding its business model - is a natural concern for me when beginning to spend time and resources on it. I very much agree. Right now the more XWiki SAS is vital the more XWiki Open Source is vital and we actually want to stay it this way, not withstanding other contributions that there can be around XWiki. My experience has also shown that our company is more committed to the software than service companies using these softwares can be. Our type of organization actuallty creates more stability around the development of Open Source software than many other types, and still it does not restrain the openness nature of the software (which is due to our commitments as a company and to the LGPL licence). xwiki.org the discussions on the boards their focus and priorities the testimonials and claims I doubt that there is a positive cashflow of revenues somehow related to the Xwiki software. Reading between the lines of your postings it seems that also vision has got lost somehow. > I don't mean to be offending - I just try to understand the motivation and/or business model behind it to get a better feeling about the risk of this project being discontinued suddenly. > So far its my impression that the project is financed by some sort of generous patronage - maybe like Mark Shuttleworth of Canoncial who became a happy and generous sponsor of Ubuntu Linux after selling his startup. > I'd be happy to hear your comment on that ;) --- Note: I'm sharing below information about XWiki SAS. I'm not 100% it is relevant to our community but since Andreas seems to find important to understand how XWiki SAS works relating to XWiki.org, I'm going into this. XWiki SAS want to be not only a "good" open source citizen, it want to be a "great" one. This means that we don't fear showing how we are and how we work and what our motivations are. --- You are actually wrong here. While XWiki SAS is not "rich", XWiki SAS is not "poor" neither "subsidised" the Canonical way or even the way many open source companies are subsidies (which is with VCs). We do have a bit of subsidies: 1/ French state: we gives us some tax cuts and funds research projects. Though this is quite classical in the French way of building tech companies to reduce our non-competitivness when it comes France's tax and social structure. We got currently 30% of our budget payed this way. 2/ Our employees, including me, are making a partial financial sacrifice to work in a company like XWiki, but we are also giving many things including the fact of getting payed to work on Open Source. Once this is said, XWiki is break-even for the last 6 years. Everybody (34 people mostly in France and Romania) gets a decent salary, and all this without external funding except the initial ones from the employees (we invested 200K). We are even more than break-even lately, because we need to fund our reserves of cash flow to manage the growth. And 100% of the XWiki SAS activity is devoted to work around the XWiki software. You can find some information here: http://www.societe.com/societe/xwiki-477865281.html The latest year (soon published) is much better with 850K revenue and benefit. Now not all the XWiki SAS employees are working on the XWiki software directly. Many are working on client projects doing custom development. We have a small support team and we have our hosting and cloud offering. We have the research team that does the funded research projects and we have a marketing team. But all the revenue from these work fund the active development of XWiki, including developers, a usability engineer, a tester, people working on documentation, etc.. The people working on support, hosting, consulting and development also participate when possible to improve the product. The global level of our engineers is quite good, since Google's HR seems to try to pitch them. All in all, I think that XWiki is quite stable. We are able to fund development (although of course we would like to fund more). We have been able to build almost all branches of the development part and we also have done all of the commercial part. I think you are a bit underestimating our success. One of the reasons I think is that we have a bigger success in France (commercially) than in other countries. If there is one thing I think we are a bit slow, it's international. I would like us to be more present in Germany for instance. In France we are doing more and more projects with XWiki and are currently progressively getting in almost any important company (that does not standardize fully on Microsoft) and also many public ministries. As for the vision, it's not that it's lost. In my view, XWiki has been lacking the "good" marketing. The one that allows to match the product better with customers needs, the one that allows to better value our strength. This is due to the fact that XWiki is very "tech" oriented by all means. By getting into "product marketing", that's what I want to work on. This will allow us to better use our "little" (they are always too little) resources on the right stuff. > Now for the targets. > a) If (in contrast to the above) there is a need to make some (more) money in a reasonable timeframe I'd go and copycat the atlassian way. AFAIK they are joining forces with some industry heavy weights. I think I remember having read about SAP selling confluence licences and services as a complemantary offer to SAP's existing user base. No surprise that atlassian claims having almost 10.000 installations. If you are interested in this topic I'd write more about what opportunities I can imagine here and what steps can be taken. Of course - developing a business like this is nothing that developers could do as a side job. This is complicated. It's hard to sell the same price as Atlassian. To do that you need a flawless product which requires no support, which means no revenu from these installs. This is good to get "known" but does not make business. Except for the Cloud offering, which is what we are doing. We are also thinking of a slightly beefed up package only available from XWiki SAS but we lack development time to work on features that don't make sense to go in the core platform (on the other hand we don't want to undermine the platform, so we are more thinking about apps). I also think you are underestimated their joining with SAP. Atlassian mostly sells Confluence to their JIRA customers. They do quite well with their direct model. They are quite focus on the techy world. On the Application/Solution side we have actually some interesting cards to play. Curriki is a very interesting product for eLearning and it is naturally sold with service. So one long term strategy is the core XE/Platform is free and "vertical" apps and "implementation" is "commercial". There are other vertical targets that make a lot of sense. > b) Succeeding as OpenSource simply by the quality of the software looks far more complicated to me. Blogging software, CMS, wikis - they all are competing for the attention of publishers and there is quite some overlap in functionality - if not in the end they all will be the same. As long as XWiki is not installed by webhosters it means that users have to install the service of their own. Only companies with IT-department and people with IT background can do that which is a severe reduction of the potential user base. But bringing 'collaboration' software to companies is more than a technical issue. Management is involved as it needs to be confident that their companies knowledge is not being shared with the wrong people. You need to build a reputation first to get there - or you are joining forces with other companies that already know the customer and have that reputation see a) Atlassian/SAP - this seems to be far more easy than b) to me. We are less inclined to try to distribute XWiki through hosters, because of our hosting and cloud offering and also because of he fact that most hosters focus on php apps. We can provide VMs for Amazon for sure and we plan to do that. Our experience shows that it's less expensive for us to support a client on our own hosting than to support him on his hosting. At this point we plan to provide VMs with support as a sellable package by XWiki SAS. We also think that this is a good package to propose through partners (resellers in different countries). So to summarize we a few big plans 1/ Our Cloud offering 2/ An AppStore with apps 3/ A packaged offering with apps available for customers and partners as VMs, etc.. 4/ Higher end Open Source solutions: education, etc.. one has not even been mentioned. sort of compatible with page layout software like Artisteer. boring now so please read my old postings on it. more options. > Besides - I think that there are also some other simple things that help better promoting the software - http://www.atlassian.com/software/confluence/videos/overview.jsp recognized media instead of the mailing list (for example stackoverflow.com) I've been thinking about getsatisfaction.com. Balasamiq seems to have quite a success with it. WDYT ? understand it might take a while until i find the time to respond. I hope I gave you some good grounds to believe in XWiki's future success. Any contribution on how to improve all parts of XWiki is always welcome. Ludovic > Andreas > Am 04.03.2011 21:27, schrieb Ludovic Dubost: >> >> Hi Andreas, >> >> Thanks for your email. This is actually good material and we need more of it. development. means making a better product which fits more the market needs. product and making it more mainstream. it. If it means working on distribution this goes beyond "Product Marketing", though I'm also interested into that. have spend the XWiki SAS marketing efforts more into showing a 'professional' face to potential customers, we plan to invest more time in open source marketing. As Vincent points outs this is also a collective effort as there is nobody better than our committers to get XWiki known in the tech world. "wordpress" but even if we can do some things that wordpress is used for, this is not what we are good at, and wordpress does not do what XWiki does. market. That's what XWiki is good at. It's not any kind of collaboration, as XWiki's way of collaboration is different than what people have been used to. since these tools build public web sites and this automatically extend their reach. in collaboration, interested in bringing their organization to that type of collaboration. and "communication" as you mentionned, but I also believes it requires more work on our end on XWiki itself. more democratize it, simplify it for newcomers, making it's powerfull features more accessible to newcomers. is it's internal Class/Object system which allows to create new data structures from the web. Unfortunately this feature requires a too steep learning curve. system XWiki should always have had. feature. It's THE "modern" way of configuring a home page for basic users. we also have plenty of refinements to do that will complete XWiki for it's "purpose", and for what it's differentiated from other tools. in distribution and communication to make XWiki more popular and widespread. you refer to the "feature" survey. Actually the current "feature survey" did include "VM" distribution. survey", to actually discuss what we should spend our effort on for XWiki. on, please bring them on. trends says. prosperous future. Amazon EC2) XWiki >>> >>> I may be paranoid but I wonder if we will see XWiki survive the next >>> couple of years if its not gaining momentum in the big world. >>> >>> just my 2 cents >>> >>> Andreas >>> >>> >>> >>> >>> >>> >>> Am 03.03.2011 14:21, schrieb Ludovic Dubost: >>>> Hi all, >>>> >>>> As many of you may know, 7 years ago, I created the XWiki Open-Source >>>> software. A few years ago, especially when Vincent arrived, I took a >>>> step back from development of the XWiki product to focus on >>>> developping XWiki SAS which allows to support the XWiki development. >>>> I've particularly spent my time making sure that the deployments of >>>> XWiki our Customers have been doing are successfull. I've left the >>>> product development work to committers who under the lead of Vincent >>>> have done amazing work in the last few years. We have provided some >>>> product marketing in addition through Guillaume's and lately Gregory's >>>> work which allowed to bring some feedback from users and customers and >>>> also bring a different less technical perspective to the XWiki Product >>>> development. Cati also joined the team and allowed us to make huge >>>> steps forward in product usability and design. >>>> >>>> Now, as XWiki SAS's project implementation team is doing great work on >>>> it's own, I've decided to involve myself more in the future of XWiki's >>>> product. I'm now the new XWiki SAS 'Product Marketing' head which >>>> means I will involve myself in community discussions about the product >>>> features actively developped, investigated for future development as >>>> well as in general discussions about the XWiki Software's future. I >>>> will try to bring the knowledge that XWiki SAS's customer, project >>>> managers, support team bring us from using XWiki in production >>>> environments to the community so that we make better decisions, more >>>> focused on developments that will allow to increase XWiki's success >>>> with end users. At XWiki SAS we have already done a lot of work to >>>> organize this feedback so that we know more things that XWiki SAS's >>>> developers and the XWiki community should work on. >>>> >>>> In the next few weeks you will therefore see me work on the >>>> investigations of future features as well as work more closely with >>>> developers whenever they feel the need on the features they implement >>>> actively. I will also manage the different surveys we have done in the >>>> past to gather feedback from our community. These surveys have still >>>> been running on the xwiki.org web site although they are now quite >>>> outdated. I will propose to review them and launch them again. >>>> >>>> If users or developers have any feedback about XWiki, about what we >>>> should work on in priority, please do send that feedback on the list >>>> (preferably). Although we have a much bigger list of great ideas than >>>> what we currently can achieve, you can help us on helping us select >>>> the most important ones that will make a difference. >>>> >>>> I would like to use this occasion to thank our great community of >>>> developers and users who help the committers every day to make XWiki >>>> better. We could not do this without all the suggestions, ideas, >>>> patches that our community provides. >>>> >>>> Thanks >>>> Ludovic >>>> >>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> devs(a)xwiki.org >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

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-tp6084764p615… Sent from the XWiki- Dev mailing list archive at Nabble.com.

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-tp6084764p615… Sent from the XWiki- Dev mailing list archive at Nabble.com.

Yeah, that sounds about right. Although I would also include the servlet container configuration (if possible) for things like port, character encoding and compression. Johannes -- View this message in context: http://xwiki.475771.n2.nabble.com/Back-to-the-future-of-XWiki-tp6084764p615… Sent from the XWiki- Dev mailing list archive at Nabble.com.