OwnCloud Statement concerning the formation of Nextcloud(owncloud.com)
owncloud.com
OwnCloud Statement concerning the formation of Nextcloud
https://owncloud.com/owncloud-statement-concerning-formation-nextcloud-frank-karlitschek/
7 comments
In the first sentence they sound very bitter: "using recently poached developers" - Almost as if they're trying to say that poaching developers is a bad thing. Developers are people, you don't own them and they owe you zero allegiance.
Actually, I should add that to my CV "poached developer" ;-)
- Lukas (Nextcloud'er - see also http://www.zdnet.com/article/owncloud-founder-forks-popular-...)
- Lukas (Nextcloud'er - see also http://www.zdnet.com/article/owncloud-founder-forks-popular-...)
Since you're referred to in that article as a "security engineer", I'll ask the following:
I know nothing of PHP other than its reputation. But apparently ownCloud is written in PHP and JavaScript. And PHP has its own "Security" section in its Wikipedia entry. And it has a reputation for security problems.
So, how "secure" (whatever that means) is ownCloud / Nextcloud? Has security been a problem for this software in real life?
I know nothing of PHP other than its reputation. But apparently ownCloud is written in PHP and JavaScript. And PHP has its own "Security" section in its Wikipedia entry. And it has a reputation for security problems.
So, how "secure" (whatever that means) is ownCloud / Nextcloud? Has security been a problem for this software in real life?
Happy to answer this. First of all: Makes using a specific programming language a software much less secure? Probably not. You can do mistakes in every programming language. But since a lot of software is written in PHP and there are also many unexperienced PHP developers this reflects kinda bad on the language.
There is often the perceiption that ownCloud would be insecure because we have so many advisories. But these are just there because we proactively look for security vulnerabilities and patch them. (see also https://statuscode.ch/2015/09/ownCloud-security-development-...)
Oh! And we also run a bug bounty program for ownCloud and Nextcloud will have one with probably even higher rewards soon! - HackerOne did even do a case study with us so it can't be too bad ;) (https://hackerone.com/resources)
There is often the perceiption that ownCloud would be insecure because we have so many advisories. But these are just there because we proactively look for security vulnerabilities and patch them. (see also https://statuscode.ch/2015/09/ownCloud-security-development-...)
Oh! And we also run a bug bounty program for ownCloud and Nextcloud will have one with probably even higher rewards soon! - HackerOne did even do a case study with us so it can't be too bad ;) (https://hackerone.com/resources)
> First of all: Makes using a specific programming language a software much less secure? Probably not.
Quite the contrary, most probably yes. Mistakes happen, but different languages make different kinds of mistakes impossible or very easy. You can't get segfault when manipulating strings in Perl or Python, while in C it takes plenty of effort to avoid.
Quite the contrary, most probably yes. Mistakes happen, but different languages make different kinds of mistakes impossible or very easy. You can't get segfault when manipulating strings in Perl or Python, while in C it takes plenty of effort to avoid.
That is true, yes. Base ruby or C or PHP make it easy to make entire classes of mistakes you won't get using certain other languages.
But many of these problems can also be caught using the right tools and framework. With Ruby, using Rails will eliminate entire groups of risks you would have without it.
This is the same with PHP and frameworks like Symfony - which, incidentally, we use large parts off. And Lukas has been working a LOT on doing this kind of work, making sure we eliminate types of problems and mistakes developers could make. Combined with training (giving talks and workshops on writing secure code to our developers at events), code reviews by him and others, static code checking and so on, you get something that is really quite secure.
I am confident enough to say that our code base is the most secure way of sharing and syncing files using open source. Of course, before you or somebody else brings it up, SSH and rsync makes for a more secure experience but that's not exactly what Nextcloud competes with so perhaps add 'that gives a dropbox-like experience' to the above qualification :D
But many of these problems can also be caught using the right tools and framework. With Ruby, using Rails will eliminate entire groups of risks you would have without it.
This is the same with PHP and frameworks like Symfony - which, incidentally, we use large parts off. And Lukas has been working a LOT on doing this kind of work, making sure we eliminate types of problems and mistakes developers could make. Combined with training (giving talks and workshops on writing secure code to our developers at events), code reviews by him and others, static code checking and so on, you get something that is really quite secure.
I am confident enough to say that our code base is the most secure way of sharing and syncing files using open source. Of course, before you or somebody else brings it up, SSH and rsync makes for a more secure experience but that's not exactly what Nextcloud competes with so perhaps add 'that gives a dropbox-like experience' to the above qualification :D
I've been following OwnCloud for years, and the one thing that has kept me from using it is the lack of delta sync. This fork has piqued my curiosity again. Is delta sync going to be a priority for NextCloud?
Whilst I have your attention ;) Are there any plans to add CalDav/iCal client functionality to NextCloud? I'd like my NextCloud server to sync with external calendars (E.g my work Google calendar) so that I only have to point my client devices at my own server.
I strongly recommend radicale with DavDroid. I've been using this set up (that only took a few minutes to complete, especially with Caddy for TLS) for months now with great success.
Radicale will also automatically commit every change into a Git repo, so you can always go back to any point in time. Just amazing.
https://www.stavros.io/posts/private-contacts-and-calendars-...
Radicale will also automatically commit every change into a Git repo, so you can always go back to any point in time. Just amazing.
https://www.stavros.io/posts/private-contacts-and-calendars-...
Radicale sounds interesting, but it looks like it's just a CalDAV server? OwnCloud/NextCloud already gives me that. What I'm looking for is a way of syncing calendars which have to be off-site, to my own server. I don't have control over the fact that my company uses Google calendars for work and I'd like to dump my Facebook events into an OwnCloud/NextCloud calendar too.
Not in the way that you require it. But you can always file an issue or enhancement request :-)
That said, we'll likely have Webcal support (https://github.com/owncloud/calendar/pull/443), that way you can at least in ownCloud view your Google calendars. (it's not synced though)
That said, we'll likely have Webcal support (https://github.com/owncloud/calendar/pull/443), that way you can at least in ownCloud view your Google calendars. (it's not synced though)
I've looked at ownCloud several times simply as a tool that I wanted to use, and each time I was turned off because of very distinctly je ne sais quoi icky feeling. For what seemed like an open source, drop-in dropbox replacement, the sales pitch seemed to add a lot of unnecessary crap.
Can anyone elaborate on said consequences? I fail to see how demoing your product in another country could have an adverse impact at home.
But this looks to be more complicated... ownCloud GmbH is unaffected? What was the purpose of having both companies then? There are many EU firms that seem to compete just fine without the Inc/LLC/Co at the end of their name
But this looks to be more complicated... ownCloud GmbH is unaffected? What was the purpose of having both companies then? There are many EU firms that seem to compete just fine without the Inc/LLC/Co at the end of their name
Yeah, that's super confusing to me as well. I see three different things here:
- nextCloud forking / poaching
- ownCloud having an event where they showed off new planned features
- the bank pulling the plug on financing
Since they're all talked about in the article, it seems as though they're related, but the links between them are really unclear.
- nextCloud forking / poaching
- ownCloud having an event where they showed off new planned features
- the bank pulling the plug on financing
Since they're all talked about in the article, it seems as though they're related, but the links between them are really unclear.
I highly doubt that the planned features are related. Seems just to be a try to make the press release look less worse...
Disclaimer: I quit ownCloud to work now at Nextcloud.
Disclaimer: I quit ownCloud to work now at Nextcloud.
My guess is that the governance and decision-making of owncloud inc, coupled with commercial debt/obligations they chose to take on, made it impossible to become commercially successful. Once the writing is on the wall for the main devs, why stick around? You can spin the code out to an unencumbered corporation (nextcloud), leave the debt behind you (owncloud), and start with a clean slate and new governance model.
That could be close or far from the truth, but one thing is clear: the 8 devs who left couldn't see a path to solvency (technical and financial) that was reachable. The most likely reasons for this are either economic realities, or inadequate political capital.
I hope they do better in their new positions.
That could be close or far from the truth, but one thing is clear: the 8 devs who left couldn't see a path to solvency (technical and financial) that was reachable. The most likely reasons for this are either economic realities, or inadequate political capital.
I hope they do better in their new positions.
Developers don't get "poached". They're not deer. The leave because something better is offered to them. Usually much better.
There's much more to this than we know yet.
There's much more to this than we know yet.
Sad to hear that the US-based employees were let go. I live in Lexington, and run by that office quite often, so it kind of hits home. Best of luck to all of you.
I'd prefer you'd phrase it "were laid off" or "fired" instead of "let go". The later is an euphemism that implies some kind of free decision.
This entire thing is just bizarre, I feel like there's a lack of openness from both sides in their communication. No side tries to inform their users about what really happened. I guess the best case is that one side (or both) can't talk because of legal proceedings which, again, would be strange for a more or less open source project.
Well, legal stuff and also you just don't badmouth people you worked with until recently. It's simply not nice, and we are still friends with some of the Inc employees.
For more info I recommend the Q&A from Frank and Jos today: https://youtube.com/watch?v=iMfokaX2r8g – we try to be as honest as we can.
Disclaimer/source: I'm one of the »poached developers«, or rather the designer. ;)
For more info I recommend the Q&A from Frank and Jos today: https://youtube.com/watch?v=iMfokaX2r8g – we try to be as honest as we can.
Disclaimer/source: I'm one of the »poached developers«, or rather the designer. ;)
Bizarre...seems like it was a hastily-put-together press release.
That escalated quickly.
I have seen such forks degenerate hugely into "they said / we promised / they suck / we're awesome", so I understand the need to delicately balance press releases between the need to inform and need to keep it civil/diplomatic, but I wish I understood more why the act of forking has caused their credit to disappear.