XWiki - The Advanced Open Source Enterprise Wiki
-
@girish My thinking exactly, and as much as I like the look of Wiki.js, it seems a fair few features have been "coming soon" for a long time, and apparently a single developer, so unlikely to be able to offer the sort of enterprise support expected with larger clients.
-
Surprised this doesn't have more upvotes!
-
I run 5 or so live Cloudrons across the businesses I'm responsible for and we've been looking for a replacement Wiki to switch to as we know Confluence on-premise is going away.
When selecting candidates for a project like this I always start by looking at the products on Cloudron,
-
firstly because it is quick and easy to install and try them (thanks guys, Cloudron is awesome!)
-
secondly because you guys have already gone through a process of vetting out the not so good products - if it has made it to Cloudron is must have merit!
I think where the case requires a larger/more complex use Confluence is a long way ahead of most of the other alternative Wikis already on Cloudron so I looked at a lot of other OS Wikis to find a better option.
XWiki does appear to be everything a larger Wiki needs there is also mention of a Confluence import - an essential tool if anyone is ever to migrate from Confluence with years of knowledge embedded in the platform.
There is also a Docker implementation of XWiki, the trend is now to deploy on Docker.
I was wondering if we are any closer to having XWiki on Cloudron...
-
-
I run 5 or so live Cloudrons across the businesses I'm responsible for and we've been looking for a replacement Wiki to switch to as we know Confluence on-premise is going away.
When selecting candidates for a project like this I always start by looking at the products on Cloudron,
-
firstly because it is quick and easy to install and try them (thanks guys, Cloudron is awesome!)
-
secondly because you guys have already gone through a process of vetting out the not so good products - if it has made it to Cloudron is must have merit!
I think where the case requires a larger/more complex use Confluence is a long way ahead of most of the other alternative Wikis already on Cloudron so I looked at a lot of other OS Wikis to find a better option.
XWiki does appear to be everything a larger Wiki needs there is also mention of a Confluence import - an essential tool if anyone is ever to migrate from Confluence with years of knowledge embedded in the platform.
There is also a Docker implementation of XWiki, the trend is now to deploy on Docker.
I was wondering if we are any closer to having XWiki on Cloudron...
-
-
Although they have many similarities in the things they do they are very different beasts to use. We found Confluence to be much smoother for end users to edit content, users could simply type what they liked, paste content from other documents and retain the formatting. More than one person could edit a document at the same time. What you saw was what would be visible instantly when saved.
I am not a Wiki.js advanced user, but my impressions were very different. Editing documents was much more like creating web content than using. You have to click the edit button, wait for it to display the edit page and then find where you were when you decided to update the content.
When you are done and then there was a long pause to render the page after you publish it, stopping you from working in the meantime - this was on a 16 processor 48GB RAM SSD-NVMe server, so hardware wasn't the issue.
All this is OK for users who consume content or those who statically create content with occasional edits, but not ideal when you want your non-Wiki savvy users to see content that needs correcting and simply want to click in the page where they see the error, change it then save it.
The big challenge for us is persuading our users to contribute and update content. It has to be a slick and pleasant experience.
-
Although they have many similarities in the things they do they are very different beasts to use. We found Confluence to be much smoother for end users to edit content, users could simply type what they liked, paste content from other documents and retain the formatting. More than one person could edit a document at the same time. What you saw was what would be visible instantly when saved.
I am not a Wiki.js advanced user, but my impressions were very different. Editing documents was much more like creating web content than using. You have to click the edit button, wait for it to display the edit page and then find where you were when you decided to update the content.
When you are done and then there was a long pause to render the page after you publish it, stopping you from working in the meantime - this was on a 16 processor 48GB RAM SSD-NVMe server, so hardware wasn't the issue.
All this is OK for users who consume content or those who statically create content with occasional edits, but not ideal when you want your non-Wiki savvy users to see content that needs correcting and simply want to click in the page where they see the error, change it then save it.
The big challenge for us is persuading our users to contribute and update content. It has to be a slick and pleasant experience.
@max Tried Bookstack?
-
@max Tried Bookstack?
@marcusquinn yep, thanks, we tried BS, simple to use and great for smaller projects. Not really suited to our needs in this case
-
Although they have many similarities in the things they do they are very different beasts to use. We found Confluence to be much smoother for end users to edit content, users could simply type what they liked, paste content from other documents and retain the formatting. More than one person could edit a document at the same time. What you saw was what would be visible instantly when saved.
I am not a Wiki.js advanced user, but my impressions were very different. Editing documents was much more like creating web content than using. You have to click the edit button, wait for it to display the edit page and then find where you were when you decided to update the content.
When you are done and then there was a long pause to render the page after you publish it, stopping you from working in the meantime - this was on a 16 processor 48GB RAM SSD-NVMe server, so hardware wasn't the issue.
All this is OK for users who consume content or those who statically create content with occasional edits, but not ideal when you want your non-Wiki savvy users to see content that needs correcting and simply want to click in the page where they see the error, change it then save it.
The big challenge for us is persuading our users to contribute and update content. It has to be a slick and pleasant experience.
@max I hear this need loud and clear. Feels like we need to run through all the App Wishlist apps with Wiki capabilities and settle on one to put effort into that gives the smoothest experience w/o having to learn/edit markup language.
-
@max I hear this need loud and clear. Feels like we need to run through all the App Wishlist apps with Wiki capabilities and settle on one to put effort into that gives the smoothest experience w/o having to learn/edit markup language.
-
@max I hear this need loud and clear. Feels like we need to run through all the App Wishlist apps with Wiki capabilities and settle on one to put effort into that gives the smoothest experience w/o having to learn/edit markup language.
@robi : it's an admirable objective, but will we not be at risk of re-starting the editor wars ?
There are so many different use cases : get 10 people in a room, we will probably get 15 use cases. And I will be responsible for at least 3 !
I think it is safer to accept diversity and ensure choice.
Just my 2p.
-
@robi : it's an admirable objective, but will we not be at risk of re-starting the editor wars ?
There are so many different use cases : get 10 people in a room, we will probably get 15 use cases. And I will be responsible for at least 3 !
I think it is safer to accept diversity and ensure choice.
Just my 2p.
@timconsidine yes, agreed, everyone will always want their own favorite one added.
For us we don't have a favorite yet, but we have a clear requirement for something that is open source, self hosting and is fully featured enough to make it a comprehensive replacement for Confluence.
I may be mistaken, but Wikiss is aimed at a different use case and is does not compete in this space. As @nebulon says it is a lightweight PHP system
-
@timconsidine yes, agreed, everyone will always want their own favorite one added.
For us we don't have a favorite yet, but we have a clear requirement for something that is open source, self hosting and is fully featured enough to make it a comprehensive replacement for Confluence.
I may be mistaken, but Wikiss is aimed at a different use case and is does not compete in this space. As @nebulon says it is a lightweight PHP system
@robi Hi, I was wondering if you had looked at this since your post back in October?
We have successfully started using XWiki for 2 corporate clients and had very good feedback. We hosted these on non-Cloudron boxes using the official XWiki images.
For one of the clients we ran the Confluence migration process which worked very well for most of the spaces (pages). We had formatting issues with a few pages which we had to fix by copying and pasting the content over. It appears there are ways to avoid this, or get support for the migration, but for us it was easier to fix the pages manually.
So we would really love to have XWiki in Cloudron and enjoy all the benefits that Cloudron brings!
-
@robi Hi, I was wondering if you had looked at this since your post back in October?
We have successfully started using XWiki for 2 corporate clients and had very good feedback. We hosted these on non-Cloudron boxes using the official XWiki images.
For one of the clients we ran the Confluence migration process which worked very well for most of the spaces (pages). We had formatting issues with a few pages which we had to fix by copying and pasting the content over. It appears there are ways to avoid this, or get support for the migration, but for us it was easier to fix the pages manually.
So we would really love to have XWiki in Cloudron and enjoy all the benefits that Cloudron brings!
-
Hi guys,
Checking in on this as I was doing some research on wikis, and from what I understand Confluence server will be sunset soon by the end of the year or so.
Looking at Xwiki, it looks really good. Very robust, lots of extensions and seems quite user-friendly.
Was wondering if there are any plans to incorporate Xwiki into the app store? Thank you!
-
Hi guys,
Checking in on this as I was doing some research on wikis, and from what I understand Confluence server will be sunset soon by the end of the year or so.
Looking at Xwiki, it looks really good. Very robust, lots of extensions and seems quite user-friendly.
Was wondering if there are any plans to incorporate Xwiki into the app store? Thank you!
-
Surprised this doesn't have more upvotes!
@jdaviescoates Yeah. It looks great!
-
just ended up here again after @luckow posted about opendesk and I was checking out the components they are integrating and saw they are usung xwiki here:
https://gitlab.opencode.de/bmi/opendesk/component-code/knowledge-management/xwiki
