How else to help out

Yesterday I blogged about how to help testing. Today, let me share how you can facilitate development in other ways. First of all - you can enable testers!

Help testers

As I mentioned, openSUSE moved to a rolling release of Factory to facilitate testing. KDE software has development snapshots for a few distributions. ownCloud is actually looking for some help with packaging - if you're interested, ping dragotin or danimo on the owncloud-client-dev IRC channel on freenode (web interface for IRC here). Thanks to everybody helping developers with this!

KDE developers hacking in the mountains of Switzerland

Coding

Of course, there is code. Almost all projects I know have developer documentation. ownCloud has the developer manual and the KDE community is writing nothing less than a book about writing software for KDE!

Of course - if you want to get into coding ownCloud, you can join us at the ownCloud Contributor Conference in in two weeks in Berlin and KDE has Akademy coming just two weeks later!

And more

Not everybody has the skills to integrate zsync in ownCloud to make it only upload changes to files or to juggle complicated API's in search for better performance in Plasma but there is plenty more you can do. Here is a KDE call for promo help as well as KDE's generic get involved page. ownCloud also features a list of what you can do to help and so does openSUSE.

Or donate...

If you don't have the time to help, there is still something: donate to support development. KDE has a page asking for donations and spends the donations mostly on organizing developer events. For example, right now, planet KDE is full of posts about Randa. Your donation makes a difference!

You can support ownCloud feature development on bountysource, where you can even put money on a specific feature you want. This provides no guarantees - a feature can easily cost tens to hundreds of hours to implement, so multiple people will have to support a feature. But your support can help a developer spend time on this feature instead of working for a client and still be able to put food on the table at home.

So, there are plenty of ways in which you can help to get the features and improvements you want. Open Source software might be available for free, but its development still costs resources - and without your help, it won't happen.

Why developers should not be testing

Short answer: because you should.

When somebody asks about their missing pet feature in KDE or ownCloud software, I always trow in a request for help in the answer. Software development is hard work and these features don't appear out of nowhere. There are only so many hours in a day to work on the a million things we all agree are important. There are many ways to help out and speed things up a little. In this blog I'd like to highlight testing because I see developers spend a lot of time testing their own software - and that is not as good as it sounds.

Developers also do testing!

You see, developers really want their software to be good. So when a Alpha or Release Candidate does not receive much testing from users, the developers take it on themselves to test it.

Developers testing software has two downsides:

• Developers tend to test the things they wrote the software to do. It might sound obvious, but usually the things that break are things the developer didn't think off: "you have 51,000 songs? Oh, I never tested the music app with more than 4,000" is what I heard just yesterday.
• And of course, it should be obvious: early and lots of testing speeds up development so you get those features you want!

Take two lessons from this:

• If you want things to work for you, YOU have to test it.
• If you want those other features, too, helping out is the name of the game.

It isn't hard

In the past I wrote an extensive article on how to test for KDE and ownCloud, too, has real nice testing documentation.

If you want to get on it now, Klaas Freitag just released ownCloud client 1.7 alpha 1 and openSUSE has moved factory to a rolling release process to make it easy to help test. KDE Applications 4.14 is at the third beta and the Release Candidate is around the corner.

Your testing doesn't just save time: it is inspiring and fun. For everybody involved. For added kicks, consider joining us at the ownCloud Contributor Conference in in two weeks in Berlin and KDE has Akademy coming just two weeks later!

Help make sure we can get our features done in time - help test and contribute your creativity and thoughts!


note: I'm not argueing here against testing by developers, rather that users should help out more! Of course, developers should make sure their code works and unit tests and automated testing are great tools for that. But I believe nothing can replace proper end-user testing in real-life environments and that can only really be properly done by end users.

ownCloud numbers

Last week, we went over some numbers related to ownCloud. Things like the number of people who contributed in the last 12 months or the speed of code flowing in on average. The numbers are impressive and you can read about them in this press release.

Analysis

Numbers can tell you a lot. One thing is of course particularly cool: the numbers are big. Really big. ownCloud has had almost 300 people contribute code to it in the last 12 months. That is a lot. Some perspective: wordpress has had 52 contributors over its lifetime! Drupal: 149. phpbb: 190. Mediawiki: 534. Joomla: 483. VLC media player: 662. ownCloud has had 566 contributors over its lifetime. This is just one metric out of many, and the comparisons are between often wildly different projects so take it with some salt.

One thing I think you can safely conclude: ownCloud is certainly in the big leagues. Looking at our competition, the ownCloud Client team alone (59 contributors over its life time) is bigger than any other open source file sync and share technology.

Why numbers

We primarily want to keep an eye on numbers to see if we are doing well or not. Anecdotal evidence is important (I really like to read all the positive feedback on the #ownCloud7 release) but hard numbers are very important too. For example, if we see fewer new people join ownCloud, we can see if we can improve developer documentation or have to offer better help for new developers on IRC.

We have good reasons to keep an eye on that. Open Source projects typically have a huge turnover (60%/year is normal), requiring us to keep attracting new contributors. Not only that, ownCloud Inc. has hired many community members and, through its marketing and sales machine, is increasing the number of ownCloud users enormously. We do numbers on our user base internally, and the number we make public (about 1.7 million at the moment) is a rather conservative estimate. And growing quickly: Germany's upcoming largest-ever cloud deployment will bring ownCloud to half a million users!

What effect does that have? For one, paid developers can create a 'freight train' effect, accelerating development to a point where it is hard for volunteers to catch up. This is a reason why it is good to split up the apps from the core and to improve the API offered by ownCloud. This makes it easier to keep changes more localized and easier to follow. Another effect is that the growing popularity of ownCloud brings more people to our mailing lists and forums, asking questions. That is a tough issue. Improvements in documentation can help here, but we can also think about other tools and ways to answer questions.

Conclusions

We can't stare ourselves blind on numbers, and we won't. Real life matters more: that is why we are working hard on preparing the ownCloud Contributor Conference later this month! But it is cool to see confirmed what we already thought: ownCloud is a very significant Free Software community. Not just its size, but also in what we are doing and how we do it!

There still is plenty of work to be done so come help out and liberate more data!