Hi Caty, +1, I think those are 2 well know wiki solutions and it’s interesting to know how XWiki compares to them. FTR Gregory Gueneau had started something like this a very long time ago but we never finalised it: http://dev.xwiki.org/xwiki/bin/view/Drafts/XWiki+competitors I haven’t fully read the 2 pages yet but form what I’ve seen so far, it looks of good quality. There are some little stuff to improve here and there but we can do that easily. I think it’s already good to start with. Thanks -Vincent

Any way to make it look better? Why are the features with a name before in each column? Also, the "Source: Wikimatrix" statement is not clearly attached to the section above it or below it. If there are extra softwares to aim at, would it make sense to add SharePoint, Office365 and Google Apps? Paul

Useful comparisons, but I wasn't sure who the expected reader would be. The XWiki vs Confluence comparison feels rather biased so wouldn't be very helpful to someone trying to make a rational decision. The table makes them seem identical (perhaps it would be useful to highlight the actual differences) aside from license. Both are listed as having a ticketing plugin, but last time I checked (admittedly over a year ago) I couldn't find a robust plugin anywhere close to Confluence's offerings. The extensions in XWiki really vary in quality, whereas Confluence has a lot of very polished plugins. That's at least been my experience, and I think there's a need to distinguish between high-quality maintained extensions vs. the more hacky ones. The lack of a markup editor in Confluence is a big difference. Might be worth illustrating further. I think the page hierarchy model is rather difference. Confluence makes chaining of child pages very easy, and access restrictions to child pages is simple to manage. XWiki was a bit clunky by comparison, but that was for 7.1 and maybe the addition of sub-spaces in more recent versions makes this easier to manage. The other big difference, to me, is in documentation. XWiki has changed a lot over the years, particularly in the API, and a lot of the material discoverable on the web is out of date. My perception is that Confluence's API has been more stable over successive releases and more effort has been invested in keeping documentation up to date. Much of this difference is just a natural outcome of the proprietary vs. open source backgrounds of each system.

Hi Bryn, Thanks for your feedback, lots of good points. See below for a point by point comment. I’ve just sent another email explaining more the context and the reason for this initiative. The goal is of course to be as unbiased as possible although it’s never fully possible to do so. At least we need to find out the parts that are not correct and remove them or word them better. The goal is to highlight the strengths of XWiki vs Confluence and MediaWiki. I agree that I’m not sure we need to list the stuff that are similar and maybe it would be better to only mention the differences. Now that said, I think the idea is also for neophytes to wikis to be able to understand this page. We need to decide which we wish to have. You seem to be knowing Confluence which is great, since it’s been more than 10 years that I haven’t used it myself. Indeed, I don’t know why there’s this "Ticket plugin” mentioned. I’ll check with Caty. XWiki certainly doesn’t have a full ticket extension right now AFAIK. The closest I can think of is the Task Application: http://extensions.xwiki.org/xwiki/bin/view/Extension/Task+Manager+Applicati… Definitely. I’ve also discussed this with others and it’s time that we start curating extensions and introduce some “Editor Picks” or “Recommended” extensions. I’ll start this in another thread real soon. Agreed. Maybe the polyglotism too (ability to use various markup syntaxes). Could you explain why it’s simpler with Confluence by comparison with, say, XWiki 7.4.3? I think this now at least as easy if not more now. Same for access restrictions to children pages. See http://platform.xwiki.org/xwiki/bin/view/Features/ContentOrganization This is not fully correct. A lot of new APIs have been introduced, showing the dynamism of the XWiki community indeed. However, we take very seriously backward-compatibility (so seriously that breaking it fails our build automatically ;)). So all that worked are still supposed to work. Do you have an example that you’ve noticed where it’s not true (it can happen from time to time when we conscientiously decide to break a recent API that we think nobody uses) . Any example? That would help to fix them. It’s certainly true that we need to improve on dev documentation (the user doc is probably ok but the dev one can be improved). Well our goal is to be open source and still be good on all fronts! :) Re Confluence, they have lots of people working on the doc vs XWiki where it’s the developers doing it, so it’s more a question of manpower than of proprietary vs open source IMO. What’s interesting though XWiki is a smaller team, we’re still progressing and innovative at least as fast (if not more) as Confluence IMO. Lots of people have commented that they prefer XWiki over Confluence. Some quotes are on https://www.xwiki.org/xwiki/bin/view/References/Testimonials Anyway, let’s focus on editing this comparison page to make it as accurate as possible. Keep the comments coming and feel free to edit the doc too if you wish. Thanks -Vincent

On 2016-05-14 14:47, Vincent Massol wrote: I think, that first simple step to improve extensions could be improving info about creating issues regarding extension. I recently tried to create one following link from standard extension homepage and didn't make to create it in right place. Cheers, R.

On Mon, May 16, 2016 at 10:45 AM, Vincent Massol <vincent(a)massol.net> wrote: However, for version 6.2.5 and later, you have a way to mitigate this limitation. You can install the Scripting Documentation Application on your own wiki (see http://extensions.xwiki.org/xwiki/bin/view/Extension/Scripting+Documentatio…). This application is dynamic, it searches and inspects bindings available to scripts in your running wiki, and provides direct access to the documentation of the corresponding Java class behind those bindings. Even scripting services added through custom extensions could be found and if these has been released on xwiki.org maven, their JavaDoc get linked as well. Unless you are using XWiki prior to 4.2 , using Wiki Component is definitely the recommended way to writes Groovy components. Registering components "by hand" from a groovy script has many drawbacks not only the restart one, and you should avoid doing that. The best is of course to write the components in Java, and install them as an extension. Thanks, -- Denis Gervalle SOFTEC sa - CEO

Hi, I finally got the time to make another iteration for these comparison pages. If anyone want to make modifications on the texts, they are available at: - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/ - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-Confluence/ - http://dev.xwiki.org/xwiki/bin/view/Drafts/Compare/XWiki-vs-MediaWiki/ They should look like: - Compare: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Co… - XWiki vs. Confluence: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Co… - XWiki vs. MediaWiki: http://design.xwiki.org/xwiki/bin/download/Proposal/XWikiOrg2017/preview_Me… I'm curious to know what you think about this version in terms of layout, validate the content, maybe you have other points that we can compare the solutions on, maybe I wrote something wrong for the solutions. Let me know, Caty On Tue, May 17, 2016 at 11:17 PM, Bryn Jeffries <bryn.jeffries(a)sydney.edu.au