Posts Tagged ‘community’

Eighty Percent ownCloud

December 23, 2018 21 comments

Recently the German computer magazin C’t posted an article about file sync solutions (“Unter eigener Regie”, C’t 23, 2018) with native sync clients. The article was pretty positive about the FOSS solution of… Nextcloud! I was wondering why they had not choosen ownCloud’s client as my feeling is that ownCloud is way more busy and innovative developing the desktop client for file synchronization together with community.


Code lines changed as of Nov. 10, 2018

That motivated me to do some investigation what the Nextcloud client actually consists of (at due date Nov. 10, 2018). I was looking into the NC desktop client git repoository grouped the numbers of commits of people that can be associated clearly to either the ownCloud- or Nextcloud project, or to “other communities” or machine commits. Since the number of commits could be misleading (maybe some commits are huge?) I did the same exercise with numbers of changed lines of code.

When looking on the changed lines, the first top six contributors to the Nextcloud desktop client are only active in the ownCloud project. Number seven is an “other community” contributor whos project the client was based on in the beginning. Number eight to eleven go to Nextcloud, with a low percentage figure.


# of commits to the Nextcloud Desktop repository as of Nov. 10, 2018

As a result, far more than 80% of the changed lines of the Nextcloud client is actually work that ownClouders did (not considering the machine commits). In the past, and also today. The number would be even higher if it considered all the commits that go into the NC repo with an NC author, but are actually ownCloud patches where the original author got lost on the way by merging them through a NC branch. It looks like the Nextcloud developers were actually adding less commits to their client than all “other community” developers so far.

No wonder, it is a fork, you might think, and that is of course true. However, to my taste these numbers are not reflecting a “constructive” fork driving things forward when we talk about sync technology.

That is all fine, and I am proud that the work we do in ownCloud is actually stimulating two projects, with different focus areas nowadays. On the other hand, I would appreciate if the users of the technology would take a closer look to understand who really innovates, drives things forward and also fixes the nasty bugs in the stack. As a matter of fairness, that should be acknowledged. That is the motivation that keeps free software contributors busy and communities proud.

ownCloud Client 1.6.1

June 30, 2014 6 comments

End of last week, we have released version 1.6.1 of the ownCloud Client, the desktop tool that does file syncing with your ownCloud. Read on the Desktop Client page how to get and install it.

The recommendation is to update your installation to this version. The previous version 1.6.0 had great new features, first and foremost the parallel up- and download of files and a way more performant handling of the local sync journal. That required a lot of code changes. Unfortunately that also brought in some bugs which are now fixed with the 1.6.1 release.

On the windows platforms, we experienced a memory leak that over time let the memory consumption of the client grow. Also, a problem in the Qt5 library that we ship for windows caused the problem that under some circumstances the wrong encryption lib was loaded, so that some people saw SSL problems on Windows.

And there were crashes. Users kept on reporting that the client was crashing after some time on windows, without a special reason. None of the developers was able to reproduce that or ever saw that. We asked for backtraces, which also can be produced on windows. Even though the backtraces looked similar, we did not find an obvious reason for the crashes. Finally, by reading through all involved code levels again and again, Olivier was able to spot some code in libneon that, again under special circumstances, could cause crashes on win.

It was a one line fix, we quickly built test packages, people tested, and finally the crashes were gone (the patch to libneon is on its way to upstream of course).

All that is now fixed in 1.6.1.

What does that show?
There not very much little “easy” bug findings any more. That is similar to the soccer world championship, where the coaches keep telling that there are no “easy opponents” any more nowadays, which is also true. These tricky problems we face in the client are hard to find, require time, often special setups if they are reproduceable at all, and advanced debugging skills. Very challenging, very much fun. But that also requires very much patience from the people who suffer from that bugs. We keep on asking questions,
ask to test new daily builds and need time to investigate stuff, and more time to release once we have the fix.

Thank you all for helping in this situation, not giving up, for again testing another daily build, reporting back, trying again. That is really big.