As Nextcloud advanced with progresses making it competitive in fully integrated government and corporate workflows, OpenCloud is getting more and more attention.
The fact, that both are collaborative cloud plattforms, designed to be selfhosted and mainly developed in/around Berlin from FOSS-Community-Surroundings, makes one ask about the differences.
The main difference I see, is the software stack
- Nextcloud, as a fork of ownCloud, kept the PHP code base and is still mainly developing in PHP
- OpenCloud, also a fork of ownCloud, did a complete rewrite in Go
Until know, Nextcloud is far more feature complete (yes I know, people complain, they should fix more bugs instead of bringing new features) than OpenCloud, if we compair it with comercial cometitors like MS Teams.
I like Nextcloud!
I deploy it for various groups, teams, associations, when ever they need something where they want to have fileshare, calendar, contacts and tasks in one place. Almost every time, when I show them the functionality of Nextcloud Groups an the sharing-possibilities, people are thrilled about it, because they didn’t expect such a feature rich tool. Although I sometimes wish it would be more performant and easier to maintain, so non-tech-people could care for their hosting themselves.
Why OpenCloud?
Now, with OpenCloud, I am asking my self, why not just contribute to the existing colab-cloud project Nextcloud. Why do your own thing?
Questions
So here I expect the Go as a somewhat game-changer (?). As you may have noticed, that I am not a developer or programmer, so maybe there are obvious advantages of that.
- Will OpenCloud, at some point, outreach Nextclouds feature completeness and performance, thanks to a more modern approach with Go?
- Will Nextcloud with their huge php stack run into problems in the future, because they cant compete with more modern architectures?
- If you would have to deploy a selfhosted cloud environment for a ~500 people organization lasting long term: Would you stick to the goo old working php stack or see possible advantages in the future of the OpenCloud approach?
Thanks :)
Question for the OP or anyone who uses OpenCloud: How does it size up in an enterprise? NextCloud has known capacity for corporate use with SSO, a desktop app, integrations…but it has all the pitfalls of PHP (granted I run it with Nginx/FastCGI and a lot of resources). The thing is, anything not PHP can be run for less overhead in terms of actual cloud costs, so I see a benefit to OpenCloud. But the features have to be there. I know a desktop app is coming soon, and thats just one of many needs.
Deployment of NC on kubernetes/docker (and maintenance thereof) is super scary. They copy config files around in dockerfile, e.g., it’s a hell of a mess. (And not just docker: I have one instance running on an old-fashioned webhosting with only ftp access and I have to manually edit .ini and apache config after each update since they’re being overwritten.) As the documentation of OCIS is growing and it gets more features, I might actually change even the larger instances, but for now I must consider it as not feature complete (since people have expectations from nextcloud that aren’t met by ocis and its extensions). Moreover, I have more trust in the long term openness of nextcloud as opposed to owncloud, for historical reasons.
So really your only reason for possibly not liking next cloud is that it’s PHP, correct?
What is the problem with PHP? I keep asking it and until now every response has been near me worthy. “Don’t like PHP because some function calls are not consistent.”, “don’t like PHP because 20 years ago it had Manu unsafe practices!”, that sort of nonsense.
What is the problem with PHP, for you?
I’m not OP, but here are my reasons:
- needs a webserver to be configured properly, in addition to the application itself - most other projects handle the server itself, so I can simply reverse proxy to it
- recent security audit found a variety of vulnerabilities - PHP has been known to have a lot of security vulnerabilities, and it’s commonly targeted due to popularity and the prevalence of these vulnerabilities; using literally anything else reduces the likelihood that you’ll be targeted by script kiddies
- since it doesn’t run an active server, things like WebSockets are wonky - AFAICT, Nextcloud solves this by using a separate Rust binary, which is weird
- using the templating feature (i.e. the whole point of PHP) takes a lot of resources vs client-side rendering, so the main sell of PHP is architecturally suspect
- I don’t use it, so if I needed to fix a bug, it would be a lot of work; I’m a lot more familiar with other languages, like Go, Rust, and Python
There are a bunch of other reasons I strongly dislike PHP, but hopefully this is enough to show why I generally prefer to avoid it. In fact, Nextcloud is my only PHP-based app, and I’m testing out OCIS now (will probably try OpenCloud soon).
Tried OCIS a while back and its way faster than NC syncing files, even the initial sync was so fast I didn’t trust it was fully done (but it was).
That being said, OCIS is missing several key features I daily use: namely proper DAV support (contacts, calendar, todo, journal, etc) as well as integrations for stuff like SeedVault for mobile backups.
I only use nextdoor for the file storage. Like Dropbox type of thing. Too get files to different computers when I need them. I don’t use any other feature.
Should I switch to opencloud?
Have you tried Synching? If you only need transferring files back and forth and no version control or snapshot-like backups, that might be even simpler
I do want the browser interface image I can’t sweep syncthing, like on a work computer, public computer, fault friends whatever.
I think that was my 1 hang up for syncthing.
Syncthing also even has basic version control, just no “web file browsing” interface.
That’s basically my use-case as well, and it’s why I’m currently switching to OCIS/OpenCloud. And OCIS (and probably OpenCloud) recently introduced the POSIX driver, so the main complaint about files not being accessible w/o some extra tool is no longer an issue. I’m planning to hard-link the data directories elsewhere to make interacting with it a bit easier.
Nextcloud’s biggest issue is performance, and PHP, while not a problem per se, doesn’t help. PHP is not designed for huge applications that need to have processes running in the background; it only runs when a request is made then stops the process, therefore it needs to load itself from scratch on every single page load.
This is because PHP uses something called CGI; the webserver (usually nginx or Apache) calls an external PHP binary to generate a page. With Go (or pretty much any other language), the app is its own server and can keep data in memory and do stuff even when no request is coming.
There’s a bunch of technical debt passed off as features, too. Like, Nextcloud runs background tasks as a cron job which is something I’ve never seen with other hosted services. It’s probably a holdover from before containerised applications were ubiquitous but honestly it comes off as jank.
Also, I wonder if there would be an argument for a Nextcloud fork that doubled down on PHP by utilising something like Laravel to put all the rendering on the server side. Right now it uses VueJS which is fine, but PHP is really best suited for server side rendering that you just can’t leverage when using a front end framework in JavaScript.
Like, Nextcloud runs background tasks as a cron job which is something I’ve never seen with other hosted services.
Drupal also uses crons to run repeated tasks. By default, Drupal cron cleans out stale database records for a few tables and breaks old caches. It can be extended by the developer, though.
It’s probably a holdover from before containerised applications were ubiquitous but honestly it comes off as jank.
PHP is pre-container and pre-virtualization, so I guess you can think of it as a hack way of getting garbage collection. To be honest, the cron’s translate pretty well to k8s cronjobs. You just use the same image as the app and override the command with the cronjob command.
Isn’t Opencloud just extended Nextcloud? (Still PHP)
Also, nextcloud core components are written in Rust, the PHP just handles incoming requests.
https://nextcloud.com/blog/nextcloud-faster-than-ever-introducing-files-high-performance-back-end/
Pretty much everything here seems to be wrong:
- OpenCloud is a fork of ownCloud OCIS, which is written in Go
- The only Rust code for NextCloud is this list, which has one repo (mentioned in your link)
- PHP handles everything except persistent client connections
I haven’t benchmarked it, but OCIS feels way faster than Nextcloud.
The scaling, in particular, is a huge benefit of PHP over practically every other technology out there: to double the performance of a PHP server, you can simply have twice as many cores and things will work without any changes needed. Not only is the scaling you get pretty much 100%, unlike other languages, this scaling continues beyond a single server!
There is so much wrong with this that it’s difficult to know where to start…
PHP does actually scale better than something like Lemmy which is written in rust
But sure, you can act like you know more than the Nextcloud devs
PHP does actually scale better than something like Lemmy which is written in rust
Okay - How then?
But sure, you can act like you know more than the Nextcloud devs
I’m a web developer too - so I feel rather qualified to speak on the subject. I don’t think the Nextcloud developers are some sort of genius team of engineers but I’m not saying they’re stupid or anything - just that PHP does not scale better than “practically every other technology out there”.
It forks or creates a thread per request. It’s horizontal scaling which is pretty common with any webapp. I don’t know why they claim PHP is special here. It’s a very common way to handle requests and you can do that with lots of languages and frameworks. More CPUs = more threads = more scaling. Throw more servers into the mix and you’re now “infinitely scaling” right? Well… No. Because I/O.
Webapps tend to be I/O bound rather than CPU bound. So asynchronous I/O leads to much better performance generally with fewer resources. Because no matter how many threads and servers you put in the app tier you’re going to be limited by the disks on your database at some point.
Exactly. The model PHP uses is explicitly worse than pretty much anything else. OpenCloud is a fork of ownCloud OCIS, which is written in Go, which scales better than most things since it uses cheap forms of concurrency, way cheaper than threads at scale. Go doesn’t use asyncio directly, it kind of fakes it with goroutines, which are incredibly cheap “threads” and the runtime abstracts away the blocking IO.
While I dont see OpenCloud replacing Nextcloud anytime soon, I always welcome new projects, especially like this to the open source community!
I don’t think it’s trying to. If you need the features Nextcloud provides, you should use Nextcloud. However, if your needs are a bit more modest and you mostly just need something that stores and retrieves files, then OpenCloud/ownCloud OCIS is probably the better bet. It’s a lot faster, scales a lot better, and it’s recent, so it doesn’t have all he baggage Nextcloud does.
My use case is very simple, I just want to store, retrieve, and edit files. So I just need to figure out Collabora or OnlyOffice integration, which should be pretty similar to how Nextcloud does it. If I end up needing the other features NextCloud offers, I’ll either switch (unlikely) or find projects that provide those features (e.g. things exist for calendar, weather, etc).
This is what you’re really looking for:
https://github.com/owncloud/ocis
Full rewrite in Go. Lots of features. Much better performance. More stable than nextcloud.
OoenCloud is a fork of this.
From the website, i can’t see how it’d different than owncloud.
There isn’t any difference. The team who was developing OCIS left own cloud and forked OCIS into OpenCloud. They’ll continue developing OpenCloud.
I’m not the biggest fan of Nextcloud but there currently isn’t a lot of good alternatives that have the same features and polish.
The issue with Nextcloud is the PHP junk it comes with. Writing something in Go is much better and it is silly to me that Nextcloud puts code in docker volumes. If they could separate out the code and data they would be in a much better position.
PHP junk
So serious question: what,.in your mind, is junk about PHP?
It is not really a proper language. It is designed to run to generate HTML dynamically but uses outside of that are pushing it. It is also problematic that Nextcloud mixes code and data. It is also slower than compiled languages like C, Go or Rust.
I think Go is really good for web applications with lots of server back end code since it is fast and static while being memory safe and easy to read. The Go syntax is cleaner than PHP and less hard to maintain.
I have a bunch of other reasons elsewhere in this thread, but I just wanted to back you up here. Go is a lot easier to deal with than PHP in many ways, and it has a lot of tools to track down issues, while also have a lot better performance. And I don’t even like Go that much (used it for the better part of a decade, pretty much since 1.0), and I much prefer Rust. But Go is 100% a good option for this use-case, since it’s mostly short-lived requests with relatively simple logic, so the various footguns I dislike about Go aren’t particularly relevant (and are way nicer than the footguns in PHP).
PHP feels like it “evolved” with hacks on top of hacks, and it’s sort of being cleaned up now. Go feels like it was “designed,” with conscious choices being made from the outset, so everything feels a lot more consistent. That makes it easier to spot bogs, performance issues, etc. Go is just the better option here, and it’s not close.
Nextcloud is more featureful (more apps like notes and hardware 2fa support). That is currently holding me to NC.
OpenCloud (fork of OCIS not original OC) is very similar when it comes to core functionality, but is missing those few apps I do not want to let go of.
Also note that nextcloud stores files in a very natural manner, where your file names and directories are stored the exact same on disk as on the interface. Opencloud does not do that. This is particularly handy if one day the app just explodes and refuses to run. With NC, you can just copy the files off the disk. Not so easy with OC.
You can enable the POSIX driver on OCIS and get a more traditional filesystem layout.
What are the apps that you would miss? I basically only use my NC as a Google drive and docs replacement, so all it has to do is store docx files and let me edit them on desktop or mobile without being glitchy and I’ve really wanted to consider OCIS or similar.
That second requirement for me seems hard because of how complex office suites are, but NC is driving me to my wit’s end with how slow and error prone it is, and how glitchy the NC office UI is (like glitches when selecting text or randomly scrolling you to the beginning).
Ocis/OpenCloud can integrate with Collabora, OnlyOffice but don’t currently have things like CalDAV, CardDAV, E2EE, Forms, Kanban boards, or other extensible features installable as plugins in Nextcloud.
If you desire a snappy and responsive cloud storage experience and don’t particularly need those things integrated into your cloud storage service, then Ocis or OpenCloud might be something to look into.
Ah I see, I guess at least that would help with the main UI, but I’m already using collabora through the collabora code server in next cloud so it sounds like I’ll probably have the same document editing experience with OCIS/opencloud. I used to use onlyoffice but after I tried out their mobile app, it started blocking me from editing documents using the next cloud app (which seemed to use the only office web UI) so I was forced to switch unless I started paying for onlyoffice.
Yes OCIS (owncloud infinity scale, a complete rewrite of the owncloud project) has a convoluted file structure and I guess OpenCloud has the same way of storing files.
This is the main drawback I see as well, but it isn’t a deal breaker for me. The way they handle the files allows OCIS and friends to work without a DB, in a stateless way I guess? This means that the entire setup is fully deterministically defined from a single file. This makes rollback very easy. So my rationale is that the files remain accessible even if a particular version decides to implode.
You can enable the POSIX driver on OCIS and get a more traditional filesystem layout. It still retains the “everything is in the filesystem” model as well.
I have no experience with Opencloud, but Nextcloud is borderline unmaintainable in my opinion. I welcome any new player in this space.
Yeah, I love NC but boy is it a pain. If there were a similar but less bulky, less clunky option that wasn’t a pain to maintain, I’d be all over that.
Why use OpenCloud instead of ownCloud Infinite Scale, which it was forked from? What’s the value proposition?
Supposedly the team left OwnCloud and forked it. So the value is that the OCIS team will be working on OpenCloud in the future.
Wow. Here’s an article that discusses it:
After the takeover, the management style changed, former ownCloud employees told heise online in confidence. And there was a lack of concrete commitments from Kiteworks regarding the long-term development of oCIS. They had worked on oCIS out of conviction, believed in its future as an open source product and also valued the joint team. For this reason, the decision was made to gradually make a new start with OpenCloud, according to several employees.
…
This is now the second time that the ownCloud code has been forked: In spring 2016, co-founder Frank Karlitschek left the company together with a dozen developers and founded Nextcloud. There, they further developed the PHP code and incorporated many additional functions.
NextCloud being so slow forced me to migrate to Seafile.
Seafile being less one-stop-shoppy made me not use it so much, but whenever I do it is always fast and responsive (unlike nextcloud, where 80% of the time I was looking at the loading indicator). Looking it up now though, it looks like it has a lot of new features I haven’t yet tried so I’m probably gonna start using it more now.
Only downside with Seafile is it’s deduplication (for me), because it stops me from easily accessing files directly (always gotta use a client). Likely a benefit for most though and I do rarely need to access a file directly on disk, just when I do, it’d be an easy shortcut for whatever I’m doing.
Check out the POSIX driver in OCIS/OpenCloud. It should keep the responsiveness of Seafile, while having a sane disk format.
Or you can try out the Seafile FUSE layer.
I’m in a similar boat, and I’ve been testing out Seafile and ownCloud OCIS, and I think I prefer OCIS. I’ll probably switch to OpenCloud though, since it seems a lot of the OCIS devs went there due to issues w/ management.
Some things I didn’t like about Seafile:
- complicated to set up - I wanted to throw it in a container, and that made it a lot more complex
- weird codebase - a lot of it’s in C, and some is in Go - not sure if they’re switching to Go eventually, or if it’s a one-off thing
- they only support MariaDB/MySQL, and I really want to avoid that - OCIS lets me just use the filesystem, which is really nice
But hey, if it works, it works, so don’t mess w/ it.
It is unclear to me what the license of OpenCloud is. Are they open source? They reference a “trial license” on their site.
Server is Apache 2.0, and frontend is AGPL v3, which seems to be the same for ownCloud OCIS, which they seem to have forked from.
Looks okay to me. Not sure how important the last two are to be honest, but I included them for completeness
https://github.com/opencloud-eu/opencloud/blob/main/LICENSE
https://github.com/opencloud-eu/web/blob/main/LICENSE
https://github.com/opencloud-eu/web-extensions/blob/main/LICENSE
https://github.com/opencloud-eu/desktop/blob/main/COPYING
https://github.com/opencloud-eu/reva/blob/main/LICENSE
https://github.com/opencloud-eu/rclone/blob/master/COPYING
The marketing statements on the website say the right things too, but they are secondary to the above, obviously:
Openness
OpenCloud is and remains open source software. This means that you can download and use the source code free of charge and without obligation. We welcome and encourage any kind of participation in the work on OpenCloud in the spirit of open source collaboration.
OpenCloud GmbH also offers paid builds of OpenCloud for use in environments where support, professional services and other services are required.
Who are we?
OpenCloud GmbH is a young company founded under the umbrella of the Heinlein Group and employs a team of developers who are familiar with the project code.
The combination of the Heinlein Group’s many years of experience in the open source business and the unwavering enthusiasm of the developers, most of whom have many years of open source experience, provides the perfect foundation for an active project. And we warmly invite everyone to join us!
The foundation
The basis of the project is a fork of a widely used open source project whose components are co-developed by developers from the science organization CERN and other active participants. OpenCloud is now being continuously developed independently by the OpenCloud community and published under the Apache 2.0 and AGPL-3.0 licenses.
In the spirit of reusability of code under free licenses, we are grateful for the strong foundation on which we are building.
It would be nice if they had a page where they laid out all the components, what the licenses are, and how things fit together. Maybe that’s somewhere in the documentation pages they have, but I didn’t see it after a quick glance. Everything looks fine, and I guess the split happened a few months ago, so maybe they’re still scrambling to get everything set up.
Anyway, it looks like a cool project, and I’ll certainly be watching it, if not switching from OCIS (had set up for testing recently).
Evaluation of the product no longer required.
NextCloud is straight up unusable to me no matter how much resources I was throwing at it.
OpenCloud seems promising. I would definitely like to play with it a little. I would also like to check check how can I help with a thing or two there.
This seems like a similar story with matrix Synapse vs Dendrite.
NextCloud is straight up unusable to me no matter how much resources I was throwing at it.
Sounds like you don’t have Redis caching properly configured.
That said, OCIS is a lot faster, and OpenCloud being forked from OCIS should do the same.
