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 :)

  • sugar_in_your_tea@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 day ago

    adds to its security and ease of handling

    PHP… security?

    Any security you get from running as a separate process/thread is undermined by sloppy language semantics and standard library. The built-in “mysql_” library was atrocious and stayed in the standard library for years (removed in 7.0, ~10 years after the previous release). Errors at least used to be really inconsistently communicated (sometimes need to call another function to check error status, sometimes returns 0 or - 1, sometimes raises exceptions). Types are pretty loose and subtly change type (e.g. when an int overflows, it becomes a float?). Variables spring into existence when you use them, so no warning about typos, shadowing, etc.

    The language wasn’t really designed, it evolved from a simple templating engine to a full fledged language, and it cleaned up a little along the way. But a lot of the old cruft still remains.

    super fast and easy to setup and get going

    Yeah, that was always the goal. All you need is a webserver and a directory of scripts and you’re golden.

    But lowering the barrier to entry comes with costs. It encourages people to just copy and paste crap until it works, I know because that’s exactly what I did when I first used PHP (JS w/ jQuery is the same way). This encourages a “just get it working” mindset instead of actually understanding what’s going on.

    You can certainly write good PHP code, my point is that it actively encourages cludgy code, which means security holes, and the best example is the language and standard library themselves.

    Web sockets work just fine

    Do they? I assume they hog a whole process/thread for themselves instead of being efficiently managed in something with proper async tooling, so it sounds like it would scale horribly. What happens if you have a million open websockets?

    They did an audit and found issues? Great, I applaud people searching and finding issues. Shall we do the same for Rust, go, or chuckle JavaScript?

    Yes. I would be very surprised if Go or Rust yield even a fraction of the vulnerabilities as PHP. Even if we expand the scope a bit to a full-fledged web server framework. And that’s with all the server bits, while PHP only worries about its standard library.

    I’ve used each of those languages. I’ve built sites in PHP, Go, and Rust, as well as Python and JavaScript (nodejs). PHP is by far the jankiest, and that’s including all the footguns w/ Go’s concurrency model.

    • Andres S@social.ridetrans.it
      link
      fedilink
      arrow-up
      1
      ·
      1 day ago

      @sugar_in_your_tea @phoenixz Hi there! If you wouldn’t mind indulging grampa for a minute - I’m a former php4 maintainer for Debian with a story.

      One time we found a bug that caused the php interpreter to crash, based on the input passed to a function. We decided it was a security issue, but even that was kind of besides the point. We reported it upstream to the php folks. They (Rasmus!) told us it was not a high priority issue, because apache would simply restart when it crashes - no big deal