3 alternative reasons why you should test Nextcloud 11 Beta

On the Nextcloud blog I just published about the beta for Nextcloud 11. The release will deliver many improvements and is worth checking out in itself, plus I put a nice clickbait-style title and gave three reasons to test it.

But I actually have some more reasons to test. You see, Nextcloud is one of the tools we need to keep our democracy working. As Frank notes on his home page:

"Privacy is the foundation of democracy"

And he is completely right. So, here are three different reasons why you should test (and help improve) Nextcloud:

1. The USA is making a massive swing towards even more spying

Obama has done nothing to curb the growth of the NSA and the scope of its operations. Secret laws spiked under his watch. Many of the folks about to be put in power by President-elect Trump favor more spying, including on US citizens, expansion of the NSA, a crackdown on whistleblowers and more. Trump's pick for CIA director calls for Snowden's execution. For what I can only guess must be giving proof of illegal government spying to dangerous terrorists like the Washington Post and the Guardian, who proceeded to win a Pulitzer prize by disclosing this information irresponsibly to the US public.

In general, as somebody who changes his stance on hugely important and complicated issues like torture in under an hour, it is impossible to predict what Trump will do with the most powerful spying agency in the world under his control, but his appreciation for dictatorial figures like Kim Jong Il and Putin gives plenty cause for concern.

2. Britain isn't doing much better

I wrote about the Snoopers' charter just some days ago - this piece of legislation goes further than any earlier piece of spying law. It allows not only passive spying but also actively hacking devices from citizens.

3. Nor is Europe

The UK is not alone. Since Snowden, Europe has complained a bit about the NSA but seems to simply follow suit, rather than doing anything about it. Germany is even introducing a bill that will allow spying on foreign journalists.

Help out!

So, how can you help? Well, test Nextcloud 11 Beta, obviously. Help others to use it, get them involved. But it goes beyond Nextcloud - promote the use of and help improve tools like Tor, Signal and others, or democracy is screwed.

Edit: updated the blog 

You are Nextcloud, too - what we will do for contributors

Cool stuff we want to do more with!

Based on feedback collected from many contributor members we've defined some plans and already made changes to how Nextcloud will be developed. Improved transparency and governance, focus on stability and architectural improvements and other improvements are covered in this blog. Much more is coming, you can join the conversation right now on our forums!

Community Input

January 2015, I ran a contributor survey to see what the ownCloud community thought about the processes, development focus and our work at the company. I shared the results by the end of April and pushed internally for the feedback to be taken serious. Some of the changes were implemented but many others were left for a future project to push forward. And Nextcloud will.

feedback and changes

Nextcloud aims to build a sustainable business, not limited by short-term, next-quarter thinking. The relationship with our community of contributors and users is central to our plans.

To quote Frank on this:

The company shouldn't be involving the community more in decision making; that's the wrong way of looking at it. There shouldn't be a fundamental separation to begin with!

And that's what we want. Saying "we're more open" just means being a more friendly ruler - Nextcloud aims to be a participant, not a king, benevolent or not! That is not to say that there should not be any direction but it shouldn't be dictated by a company anymore. Of course, people can decide what they work on, and the company gets to decide what it pays its employees to do. Now there are changes in how we manage our employees too, with far less micromanagement and more freedom. But that's for another blog.

Let's go over the specific pieces of feedback mentioned in the email and received from contributors in other ways and note how Nextcloud intends to address them.

Development

ownCloud is fun and relatively easy to contribute to, with a mostly well running review process and release cycle. There were some practical requests and suggestions as well as concerns about the strain the growth of our project has put on the core developers.

Dealing with Pull Requests

A major issue as detailed in many comments was that it often takes too long for pull requests to be merged. That is, contributions are not handled fast or at all. The result is that, with Core moving fast, contributions get out of sync, no longer apply and are effectively lost. As the graphs below show, the number of pull requests taking longer than 6 months to be merged is rising rapidly while the company is contributing less to development relative to volunteers. Don't get me wrong, it's great to have a growing community! But the support for development from the company needs to keep up with the pace.

Respecting contributions by being responsive and getting them merged will be our number one development priority at Nextcloud. As research by Mozilla has shown, reacting swiftly to contributions is crucial for growing community and we intend to grow and nurture our contributor base, recognizing outside input as a key driver of growth and success.

More stability

A general point made was that it'd be good to focus more on stability and performance. Some of that has been implemented with the 8.x series and automated testing improvements done over the last year. An especially sore point in terms of stability is the upgrade process, as was very visible with the 9.0 release that is still not available for users of the built in updater app. We will soon blog about the Nextcloud plans with regard to the updater.

Architectural improvements

It was mentioned that some parts of ownCloud are in need of serious architectural love and refactoring. ownCloud has been traditionally rather restrained in this regard and people worried that this "impairs competent developers". While being conservative is important with regards to building a platform (stability and compatibility!) many improvements made their way into the 8 and 9 releases. To preserve a healthy balance, we want to introduce an Architecture team to make decisions that have a big impact on the code base. More details will follow.

Another area of improvement would be to communicate more about architectural changes. Frank has already done a series of blogs about Federation in the past and more will follow.

Apps: support for Calendar, Contacts and Spreed

Many pointed out that apps are extremely important for ownCloud and we should work more on that. Frank has always emphasized the importance of building a platform and for Nextcloud this will be a central goal.

Nextcloud will officially support the Calendar and Contacts apps and supercharge their development. The Spreed.ME app will bring fully supported audio and video chat to ownCloud. We'll also invest in growing and improving our API for these and other applications.

Process

Some smallish process improvements were requested. More logical labels and tags, for example, which have been pretty much cleaned up since then. Another thing was that big pull requests are often a pain in the ass to get merged and we should tell contributors to cut their work in smaller pieces. This was added to the documentation.

Decision making

Most people were positive about the technical direction of ownCloud - test-driven, stability, architectural work, those were great improvements. Decision making processes in the technical area were not considered very transparent. Comments were even more harsh about the project-wide decision making process.

People feel decisions are often done behind closeddoors. Nextcloud will address this, in part by a new architecture team and in another part by getting rid of most 'hidden' communication channels like internal IRC and mailing lists. We also plan on talking more about our goals and plans in blogs and such.

Longer term planning is a major sticking point: there is little of it public. We need to discuss, together, how to do longer term planning. This doesn't fit too well with github. Thoughts welcome!

Communication channels

Several people have noted that we've got too many, confusing and overlapping communication channels. We've already eliminated one: mailing lists. We still have a newsletter for those who want to follow us and the blog roll on nextcloud.com/news. For technical discussions we keep using github (which now links commits to pull requests so you can find the discussion behind code) and we'll discuss more general subjects on the forum. Speaking of which, it's now on discourse - a massive improvement I'd say. And email fans can use email to communicate with people on the forum!

Governance

It was already mentioned here and there but there are two other big changes. First, we want the Nextcloud trademarks to be owned by the community, like the ownCloud one should have been. So we will set up a foundation soon which will control the trademark (not have it sub-licensed!) and more in the future.

Second, we will get rid of the Contributor License Agreement. You don't need to sign anything to contribute to Nextcloud.

Third, without CLA there are no proprietary apps part of Nextcloud. We won't be artificially crippling Nextcloud just to get some checkmark on a feature list on the enterprise side. At the same time, of course much functionality is needed for companies, stuff that they need (and home users don't). We will provide that for sure, including migration path, but this time as stand-alone tools. No more exclusivity for a single company, allowing it to do things others can't for legal reason. Our power is in employing the people who write the code, so we can give the best support and develop the best features. If another comes and tops us, well, we should've done better.

Users

There will be improvements for users, too. Already mentioned were our plans to support the Calendar and Contacts apps, Mail too, perhaps more. And of course with Spreed.ME we will integrate open source, WebRTC based video conferencing. There is more coming - for a future blog!

That's all? Nope.

Now I know this is a long blog with lots of details. No surprise, it is based on things we've wanted to improve for many years but could not. Now we can and we will. This is not the end of it, other suggestions and thoughts are more than welcome. Get involved!

Moving on from ownCloud

A few days ago, I published my last blogpost as ’ownCloud’ on our blog roll about the ownCloud community having grown by 80% in the last year. Talk about leaving on a high note!

Yes, I’ll be leaving ownCloud, Inc. - but not the community. As the numbers from my last post make clear, the ownCloud community is doing awesome. It is growing at an exponential rate and while that in itself poses challenges, the community is healthy and doing great.

I joined in 2014, when ownCloud, Inc. had about 36 employees. The community grew that year, according to our history page, from 1 million users to 2.2 while the number of average coders per month went from 62 to 76. For me, the coolest thing that year was the ownCloud Contributor Conference, that brought together 100 contributors for a week of hacking at the university of Berlin. A stressful, but awesome week. Though, my first meeting most of my colleagues was some months earlier at the Stuttgart meetup and my first release was ownCloud 7 not long before the event.

2015 was more of that - our history page has a great overview and I’m darn proud of having been a part of all those things. 2016 brought ownCloud 9, a major release, which was accompanied by an overhaul of owncloud.org, I hope you like our new website!

Not everything is finished, of course. We’re still smack in the middle of awesome work with Collabora and Spreed as well as the WDLabs PiDrive project - I just finished and published this page about it. All great stuff which has great momentum and will certainly move forward.

Myself, I’ll stay around in the community. I’ll talk about the awesome stuff that is coming next early June but until then, don’t hesitate to contact me if you’ve got any questions about ownCloud or anything else. You can still catch me on jos@opensuse.org ;-)

Home Automation, AI and the Crownstone

Waiting for that future where you're dressed automatically? I'd rather do that myself and don't have a Roomba yet but as tech marches on, we'll get more automation in our homes.

With more and more 1984, Brave New World and Farenheit 451 being brought to this century by our esteemed leadership and our corporate overlords, I'm hoping that this tech will be ours, rather than theirs.

Enter a nice player in the "automate stuff" arena: Dobots. In their own words:

Our goal: Really smart buildings. Really smart robots. We're a startup in AiTech with applications in CleanTech and GreenTech.

What makes them nice is that they are real Open Source folks, putting what they code on github under a free license and working with and building on open tech.

They previously did industrial cleaning robots and other stuff. Currently, they are running a kickstarter for a smart power outlet as a first foray into home automation. EDIT: they've instead decided to, for the first run, only create EU plugs as there was little interest in the US. You can order them on the crownstone.rocks website.

Enter the Crownstone

How is AI relevant for power outlets? More than you'd think. One example is SLAM. SLAM (Simultaneous Localization And Mapping) tries to answer two key questions in Robotics:

• Robot Localization: “Where is the Robot?”
• Robot Mapping: “What does the world around the Robot look like?”

(read more about SLAM here)

Dobots has turned this around in the crownstone, using these algorithms to map your house and localize people in it. Yes, the Crownstones know where THEY are and where YOU are. While not exactly a localization tech, the Crownstone uses Bluetooth LE for this so it works with pretty much any device. And the best part: their localization code is, in Javascript, to be found on github!

This means you need no motion detectors or cameras to know where people are in the house, keeping things simpler and cheaper. But Bluetooth LE is used for managing the Crownstones, too. Rather than turning to WiFi or (expensive) central control hubs, Dobots lets the Crownstones automatically create a mesh network. Your smartphone acts as control hub (apps on github, of course) though you can also take a Raspberry Pi, plug in a bluetooth usb module and have it act as hub. That way, even when you're not at home, you can control devices or get notificationsthat, say, your television, computer or other devices are getting unplugged. It uses XMPP and WebRTC to get through your firewall and guess where you can find the Cordova based Raspberry Pi app...



But there's another innovation in there which helps avoid extra devices and complicated configuration: extremely fine grained power usage monitoring. Yeah, it can tell you how much power your fridge and TV use but more importantly: it can automatically detect which device you connect to it! So when you leave the house, it can kill power to your tv but not your fridge... I've been told they think they eventually will be able to figure out different makes and models of laptops based on their power signature. Now is that cool, or what?

The algorithms to do this are currently Matlab code but once finalized, they'll be on github, too.

Dobots regularly works with students who get to play with their tech and come up with new, innovative use cases. And this works wonders. Just some results from a recent hackathon:

• Team 1 developed ChildLock. Devices are only turned on when adults are in proximity.
• Team 3 developed Start VR. Virtual reality that allows you to picture your own furniture in an Ikea store.
• Team 4 introduced Never Lose. Lights indicate for elderly people where they have lost items with iBeacons.
• Team 5 used Crownstones to indicate the way to store employees.
• Team 6 worked on Tommy. An AI that analyzes patterns of daily life to combat loneliness.
• Team 7 developed Any Morning. Your phone using the Crownstones guides you to your morning routines to make you leave your home on time.
• Team 10 implemented Tipspromenad. Kids have to find objects in a place combined with solving puzzles for fun!
• Team 11 developed SpotOn. In emergency situations lights indicate how to flee a building

All together

The Crownstone has some nice advantages over the competition:

• Functional. Dimmer, iBeacon, a current measuring device, a standby killer and more in one.
• Cheap: you get 2 ready-made or 3 do-it-yourself for Eur 75 but there's no need for a hub, motion sensors or other stuff.
• Open. Using open protocols and code on github and I expect interesting applications to come from the community.

I did an interview with their COO - for more background, read it on LinuxVeda.

So I say - if you are looking to start with some basic home automation, go and get some Crownstones and get started!

BREAKING: Netneutrality more complex than you thought!

It was simple: netneutrality is good. Companies shouldn't be able to buy their way on a fast lane! That stifles innovation and competition and risks ruining the internet. Just like John Oliver explained it! But now the Brazilians are making things complicated.

Brazil was one of the first countries to introduce strong Net Neutrality laws, points for them. But now, Brazilian banks and local government are paying for the data bundles of users! Heresy! Why?

Well, many Brazilians can't afford a data bundle. Yet they need to bank, or order new passports. And it turns out that handling people in person at the office is more expensive for the banks and local governments than have them use an app on their phone. So, they made a deal with some local providers: users, even without a data bundle, can do their banking online and order their passports without paying. That seems like a win-win.

Zero rating, as this practice is called, exempts some services from from the data bundle - exactly what Brasil is doing. It is used widely in India ("internet.org") and in Chile it offered many people access to a limited set of internet services - until it was outlawed. But in a country where only a quarter of the citizens has access to broadband internet, aren't we doing the population a disservice by taking away their internet access, however limited?

Zero rating is essentially the equivalent of a collect call - the receiver pays. What is wrong with that? Even wikimedia supports zero rating!

It isn't win-win but lose-it-all

The thing is - the provider will be the gate keeper of what services you can. You are allowed only on a piece of the internet, being blocked not by technical boundaries but by a business model. A model which allows providers to extract more money from their business than they otherwise would have - not by offering more services, but by offering less.

The result will inevitably be lower data caps because it forces more companies to pay for zero rating! This is exactly what happens in Canada, where $45 gets you 2GB of data - compare that to the price of 8 dollars for the same amount in Finland. Canada is now changing the rules. Cable providers have figured that out, too, and try imposing limits while excepting certain services. And indeed, when providers introduce zero rating, prices go up!


Interestingly, when zero-rating is squashed, the opposite happens. When the government forbade zero rating in the Netherlands, its largest provider KPN responded by doubling their users' data caps without a price hike.

Thus, my suggestion to the Brazil government would be: work with providers to get indiscriminate data bundles to more users, rather than empowering providers to control their users' Internet usage.


Zero rating exist by virtue of artificial Internet scarcity in the form of usage caps and it is not part of the solution to bringing Internet access to everybody. It is part of the problem.

What's Holding ownCloud Back?

In the recent article about the ownCloud event program, I pointed out that while ownCloud has 2.5 million users, it is a drop in the ocean looking at the number of Internet users (a little over 4 billion today). The announcement of the "Let's Encrypt" initiative from the Electronic Frontier Foundation, Mozilla and others prompted me to write this: it is one step in the direction of removing the limitations holding back wider ownCloud adoption. What does the future hold?

Easy ownCloud

As Frank pointed out in his blog on the future of PHP, ownCloud has ease of use as an explicit and very important goal. And while the technological choices made aren't always so exciting and bleeding edge, they do result in ownCloud being very easy to deploy on a very wide range of devices. Plenty of tutorials exist showing it running on everything from Rasberry Pi devices to big iron at organizations like CERN, where physicists looking for the origins of the universe are routing hundreds of terrabytes of data through their CernBOX build on ownCloud, sharing and collaborating on the data analysis.

Limitations

Unfortunately, there are limitations outside of what ownCloud can directly control.

In the database area, SQLite is default because it requires no manual setup whatsoever. But performance suffers when an installation has more than a trivial amount of data. When sharing with more than 15 users or indexing your mp3 connection, SQLite usage leads to frequent time-outs and other issues!

Another, more serious issue, is the architecture of the current internet. Most users are set up at home behind a firewall provided by their internet router. While this provides some additional security, it is mainly because the limited number of unique addresses available in the still widely-used 'IPv4' protocol. It simply is impossible to assign a unique address to each device connected to your internet at home. But this means your server will not be reachable when you're not home, unless you adjust some settings on your router. While we can configure some routers automatically, most we can't and as every router is different, an easy 'generic' how-to can't be provided either.

A third issue is that an ideal ownCloud platform would be small and cheap devices like the Raspberry Pi, but these are almost all based on 32bit CPU's. Due to technical limitations in the platform ownCloud builds on, this means you won't be able to have it handle files bigger than about 4 gigabyte! That is a big limitation if you'd like to store your virtual machine or Blue Ray collection on your ownCloud.

The fourth issue I see is security. While not the biggest problem of the three, setting up a server to be secure, including a decent SSL certificate, is not easy. I personally couldn't figure it out and while I'm new to server things, I am not a technology hater by any means. My parents wouldn't ever be able to figure it out and more importantly, they wouldn't want to!

Solutions

These four issues to wider ownCloud adoption aren't the only ones, but as far as I can tell, the biggest. So how do we deal with it?

There are several routes to an even easier ownCloud installation. Having a pre-setup operating system in the form of a container (Docker?) or a virtual machine can take care of much of the trouble around database setup and help a lot with the security issue. However, it can't run on light hardware like a Raspberry Pi and doesn't deal with the file size problem.

When it comes to the address limitations, the internet is slowly transitioning to IPv6 which will provide more unique addresses for each person than IPv4 offered in total (see here how Google explains IPv6). So, essentially, we just have to wait for this problem to be solved.

The hardware problem is also working on solving itself: the upcoming new swath of ARM CPU's (and Intel CPU's targeting the embedded market) are fully 64 capable so while current-gen Raspberry Pi devices (and other embedded devices like routers!) aren't perfect for ownCloud, a year from now many new devices will be perfectly capable of providing a great ownCloud experience.

The Electronic Frontier Foundation's "Let's Encrypt" initiative offers a (partial) solution for the security issue. Without it, a pre-configured ownCloud system will most likely be set up to use a self-signed certificate. While secure in principle, it always warns visitors of the self-signed state and thus isn't ideal. Let's Encrypt provides an automated and more importantly free (in terms of cost) solution for this.

And now

While I'd love for all these changes to be implemented yesterday, in reality we simply have to wait for the transitioning to IPv6 and 64bit CPU's. In the mean time, we can already start working on integrating Let's Encrypt into virtual machine and Docker images with a pre-configured MySQL (or MariaDB) and perhaps recommend people to run them on a 64bit capable system like a modern NAS or a NUC. The ownCloud-in-a-Box image on SUSE Studio is a great start!

Meanwhile, getting ownCloud ready to run on a wider range of devices and perform a wider range of 'cloudy' functions like running as backend of the Chromebook devices (see this page and ping me if you want to get involved) should be on the agenda as well. I personally look forward to more 'social' integration in ownCloud, like the ability to comment on images or other data and share these with the people you share files with. We're on it, tags sharing is integrated for ownCloud 8 and a generic metadata repo was created (empty still). Get involved if you can!

Obviously, telling people about ownCloud is still important - which is what the ownCloud event program is all about - and help is welcome. Go to owncloud.org/promote and share the love!

Security doesn't discriminate

Yesterday I published a long blog about privacy and why it matters. Unfortunately, as Commit Strip eloquently paints below, privacy almost always gives away to the same old arguments...

That was all too typical in Holder's call to tech companies to leave device back doors open to police. What Holder doesn't seem to get (or care about!) is that a back door doesn't discriminate who gets through. If you leave your door unlocked so the police can get in, do I really have to tell you it also means thieves can come in?

It is no different in 'cyberspace'. There ARE differences between real life and online life - but in this is not one of them. Security Ninja Bruce Schneier pointed out the effect of this reality:

"We are all vulnerable to everyone because the NSA wanted us to be vulnerable to them."

In his blog from 2 weeks ago, he continued:

"We have one infrastructure. We can't choose a world where the US gets to spy and the Chinese don't. We get to choose a world where everyone can spy, or a world where no one can spy. We can be secure from everyone, or vulnerable to anyone. And I'm tired of us choosing surveillance over security."

Me too, Bruce. Me too. And it's even more irritating that the people who are supposed to protect us keep lying about it all.

Later addition

October 3 Vox put the issue in a historical perspective. More details are in this New York Times article from 1994.

I spend some time collecting and commenting on the most interesting quotes:

"Wiretapping is among law enforcement's most cherished weapons. Only 919 Federal, state and local taps were authorized last year, but police agencies consider them essential to fighting crime."

We know things have changed, and not just in the US. In 2011, the Berliner police collected data from 4.2 MILLION mobile phones just to catch ONE group of car thieves... Shows how government surveillance has begun to spin out of control, if you ask me.

"Still, the effect of strong crypto on N.S.A. operations is not difficult to imagine. The agency is charged with signals intelligence, and it is widely assumed that it monitors all the communications between borders and probably much of the traffic within foreign countries. (It is barred from intercepting domestic communications.)"

Thanks to Snowden, we know that they're now heavily intercepting domestic communications. Some things have changed (guardian article on effects of the Snowden leaks) but we have a long way to go. If you want to know more about Snowden - this article on Wired is among the very best.

The article talks about introducing a security chip (Clipper) with a back door for Law enforcement, but correctly asks:

"What sort of nuclear terrorist would choose Clipper?"

Indeed:

"Some people criticize Clipper on the basis that truly sophisticated criminals would never use it, preferring other easily obtained systems that use high-grade cryptography."

"The Government understands the impossibility of eradicating strong crypto. Its objective is instead to prevent unbreakable encryption from becoming rountine. If that happens, even the stupidest criminal would be liberated from the threat of surveillance. But by making Clipper the standard, the Government is betting that only a tiny percentage of users would use other encryption or try to defeat the Clipper."

In other words, this would do the same thing as famously copyright protection on music CD's did: legitmate use (like copying the songs from the album you own to your iPod) was made impossible, but slightly more sophisticated, often professional music sharers had no issues with the 'protection'.

"This seems to be the Government's intent -- to encourage "crypto lite," strong enough to protect communications from casual intruders but not from Government itself."

Making us thus all vulnerable to hackers, foreign governments etc etc. Nothing new under the sun!

A quote from the documentation of PGP gives this same response:

"If privacy is outlawed, only outlaws will have privacy. Intelligence agencies have access to good cryptographic technology. So do the big arms and drug traffickers. So do defense contractors, oil companies, and other corporate giants. But ordinary people and grassroots political organizations mostly have not had access to affordable 'military grade' public-key cryptographic technology."

Amen.

The Vox article also points out the Washington Post had to correct a op-ed by former FBI official Ronald Hosko who gave a specific example where encryption would have thwarted a law enforcement investigation and cost lives - but turned out to be wrong. Honestly, if the one example the FBI has turns out to be wrong, how much is there to say for their argument? I don't think encryption will do as much harm as they like to claim.

XKCD already comically explained this: the government has many means of getting information from its citizens, and encryption doesn't change that much.



EDIT october 6: I can keep updating this post forever, but I won't - only one more link: Bruce Schneier weighted in, calling it Return of the Crypto Wars - referring to the fight around the Clipper chip I described above.

EDIT 2: Rather than writing a new blog, I thought I'd add another piece here. I've made the point that the pervasive spying doesn't help. Just, for reference, some evidence in the form of a series of attacks where the perpetrators were known but the secret service simply lacked the resources or insight to follow and catch them:

• September 11 2001 attacks
• Murder of two people at anti-Muslim exhibition in Texas
• Murder of Theo van Gogh,
• Charlie Hebdo attacker
• Attack on the Thalys
• Failed attack at a flight from Amsterdam to Detroit
• Attack in Tunis
• The attack in Kopenhagen

Via a blog from Dutch journalist De Winter

Of course this is still all complaining in the margins, no matter how horrible 'terrorism' is, it isn't a cause for death which is even remotely relevant in comparison to serious threats to people's lives like smoking or car accidents... And indeed, as the word points out: it is about 'terror'. Making people afraid. Not actually killing or harming them - ISIS and friends don't have the resources to do any real harm. They can just scare us into changing our society. Which our politicians are all to happy to do, well supported by the media (see this video).

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!

It all comes together: no more Software Compilation but more KDE!

KDE 4.0 demo in Dresden, 2007 (short hair time, yes)

With the KDE 4.0 release we had the issue that everything was one big blob: the libraries, the desktop and the applications, all inter-dependent.

Back then, at the end of 2007, the libraries and many of the applications were in a very good shape. Especially the KDE Edu applications I remember: they were stable, pretty and awesome for many months already before the release and their developers were itching to get their code to users. I had made a blog post with cool video's of KDE edu apps in October 2007. Here is Kalzium at that point:



Unfortunately, the desktop, having undergone a HUGE rewrite, was not at that same level of quality. As I wrote later that Month:

"When I show people the state of Plasma, they're like "hmm, that's not good". So I then proceed to show the Edu and Games, cheers them right up."

But the last release of KDE had been in 2005 (!!) and after more than two years, we really wanted the new and improved apps to get out to users. The desktop was basically workable so we decided to release. Code that is not in users hands rots away...

We all know how that went - distributions shipped it as default and the internet erupted with hate.

Doing better now

So, for the 5 series, we split it all up: Frameworks 5.0 (the new name of our modularized libraries) was released last week, the desktop came out yesterday and the Applications still mostly have to start moving to Qt5/Frameworks 5... We weren't forced to release half-baked stuff but everything came 'when done'.

KDE is now People. And dragons.

Better separation: rebranding

That was possible because we rebranded 'KDE' to mean community in November of 2009. This created (over time...) separate brands  for 'Plasma', 'Applications' and 'Platform' (now 'Frameworks') which could release on their own. Could being the operative term here, as we kept releasing it together.

That created quite some branding confusion, also because we had not thought through all the issues we would bump into. So when we finally decoupled releases at the release of Plasma 4.11 (the latest release in the 4.x series) and the KDE Platform at 4.9 (although that got some serious updates since then and has kept increasing version number for packaging convenience), it was largely ignored.

Which in turn created some confusion when Frameworks 5.0 came out - several people asked 'where can I get KDE 5', expecting to run the desktop and applications already. Well, I'm quite OK with users saying 'I use KDE' as long as they mean Plasma and realize there is more to KDE than the desktop. Because when I say I use Microsoft, I am not lying. I've always been a huge fan... of their keyboards. Not joking, their operating system wasn't great last time I used it but I love the 'comfort curve' series of keyboards. They should stick to hardware, clearly their strongest point.

In hindsight, we probably better would have waited until there was a real need for the rebranding - like today, or in 2013, when Plasma stopped releasing. Then again, we did expect that to come soon - there already had been talks about disconnecting the releases, it just didn't happen. Well, hindsight is always 20-20, they say...

And as the title points out - there is no more need for the 'Software Compilation' term, which was invented to solve the confusion of 'KDE releases three separate things but all at once'. We no longer release the Applications, Desktop and Libraries at once...

Better communication

Another thing we changed is our communication. In the KDE 4 times, what we did was PROMO: being as positive as one could be ;-)

Since then, we've learned a little actual marketing. Perception management and fancy stuff like that. Including properly explaining what something is and is not ready for! That's why I wrote a known issues section for the Beta of Plasma including:

"With a substantial new toolkit stack below come exciting new crashes and problems that need time to be shaken out."

With a clear section on where we stand in the final release announcement on the dot (See Suitability and Updates on the bottom of the article) we have made clear what the state is - and that we don't think distributions should ship Plasma 5.0 as default. And distributions have picked up on this - at least neither Kubuntu nor openSUSE will ship their upcoming release based on Plasma 5.0.

Forward

Now, the future. Plasma 5.0 is out, and on a 3-month release cycle. Frameworks comes with a new version every month, the Applications are still at 4.13 with a beta of 4.14 out last week. After 4.14 is out, the work on a Frameworks 5/Qt 5 port will commence full-steam but some applications will be ready before others. How will we deal with that conundrum? I don't know yet. There might be two KDE Application releases for a while, as some applications will take longer to get ported than others.

But we're better positioned than ever to bring innovations to the Linux Desktop. So let's see what the future brings!

(Ok, I do have SOME thoughts on where KDE, is going, see Part 1 and Part 2)

Frameworks 5.0 is out!

It took us a while but here it is. And I think we did quite a decent job communicating this to the outside world with articles like

• An extensive overview of and background on Frameworks 5
• Tech Preview release article with lots of info
• How KDE contributed to Qt 5.2 to ready it as base for Frameworks 5
• The mini series of 'where KDE is going' discussed Frameworks and its importance pt 1, pt 2
• Article for Linux.com about why Frameworks is a big deal for Free Software

For the final release (this one, I mean) we had far less time than I had hoped - I wrote most of the announcement last Saturday (though we started a few days earlier and had our already-prepared communication plan) and we didn't really rally as much of our 'friends' to help promote the release as I had planned initially. And yesterday my internet broke down so in the end, Mario and Jonathan R had to put most of it live, half a day behind plan. But despite these issues, it did turn out quite well I think.

Now the communication is done and it is up to the code to prove itself in real life!

As I blogged before, I think this is a huge deal for Free Software on desktops AND mobile devices - it goes far beyond the KDE community. Qt is by far the largest Free Software ecosystem doing native (non-web, I mean) end-user software, but much of that is proprietary. Which makes sense - Digia and the other companies in and around Qt have to make money and don't have 'spreading Free Software' as their prime goal. Frameworks introduces a genuine FOSS touch to that, hopefully bringing many of these developers in touch with the KDE community and the Open Source development processes.

Oh, and just a few more days to go to support Randa 2014, and support it really needs. Remember, this is where Frameworks started! Let's see what KDE comes up with this year at Randa ;-)

oSC13, Strategy and Stable

At the openSUSE conference there were discussions about the future of openSUSE. Last Wednesday I summarized some of the ideas around Factory. Today I blog about the openSUSE releases.

Note: This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Stable - big picture

On the Stable release future, things are much more in the air. In his keynote, Ralf hinted that SUSE has some ideas about how the future of openSUSE should look:

• Open Governance - SUSE wants openSUSE to be successful and independently strong. Ralf noted that SUSE does not expect or aim to make money on openSUSE directly; other parties however are very much welcome to build a business around openSUSE.
• Filling the gap - SUSE and openSUSE have a great win-win relationship. But SUSE notices a gap between openSUSE and SLE in the market: SLE is oriented to large enterprises and the current openSUSE has a too wide market to feed, from newbies to hard core developers to professionals.

This is, from the SUSE side, the big picture; SUSE wants to provide room in the openSUSE ecosystem for initiatives, both from volunteers and from the commercial side. And SUSE would like openSUSE to move up a little, offer solutions for people serious about computing in a professional capacity. But what does this mean exactly?

Concrete changes

Let's start again with what came out with the keynote. Ralf essentially summarized some of SUSE and openSUSE's history and talked about our current situation. openSUSE Stable, our final release coming out every 8 months, is a compromise between stability and being-up-to-date. But this compromise was made in a time when far less people used the many repositories on OBS offering more up-to-date software; and before Tumbleweed and Evergreen saw the light of day. It is 2013 now and Ralf hinted at a possible re-evaluation of the choices that were made back then: perhaps, we should limit our scope, improve quality and increase the life cycle of openSUSE?

Improve quality

Let's talk about quality first. This is difficult, harder than it seems. Factory has some automated testing and openQA got better thanks to some recent work, but nothing can replace human testing and there is not enough of it. There is room for improving our processes here, but there is also the fact that some people in our community care more about Stable and others more about moving forward with Factory. We need to find a way to service the needs of both. Having Factory more stable, hence more usable on a day-to-day base, would be a great first step here.

Limit the scope

If you want to do something well, you should focus on it. It's the Unix philosophy many of us share: do one thing, and do it well. openSUSE is well known for doing everything a bit - making everybody a little happy, but nobody REALLY happy. Part of why this model is still working reasonably well is thanks to OBS - which has grown in this role. Many, many users these days use the openSUSE release as simply a base for their favorite OBS repositories. If we want to improve quality and lengthen the life cycle, we can use this model.

For example, parts of openSUSE which can be and are maintained longer get in the stable releases; other parts with a shorter life cycle (Firefox for example) stay on OBS. This means that being part of Stable depends on commitment from both upstream and the openSUSE maintainers of the packages; as well as testing capacity and our quality standards.

Lengthen life cycle

A portion of the openSUSE users would like to have a longer release cycle - the interest in Evergreen and questions on our mailing lists and forums make that clear. SUSE has dedicated a set amount of resources for maintaining openSUSE releases; checking security and entering bug fixes. The maintenance process is now opened up and some teams in openSUSE are contributing to the maintenance, lowering the load on the SUSE maintenance team. A smaller scope (resulting in a smaller release) would do the same, as Ralf mentioned in his keynote. This will have to be a part of the solution we're looking for to increase our maintenance window.

In practice

To put it in perspective, three examples of how we could do this. Keep in mind that sticking to the openSUSE-has-all-and-comes-every-8-months model is of course also an option...

Rings, rings, and rolling!

Presume we will have rings in Factory (see blog from Wednesday)? Let's put them in the distro. There's the core with ring 0 and ring 1 ("everything up to X"). It is released every 2 years and maintained for 3. Then, there is ring 2, with the basic desktops and their devel frameworks. They are maintained 2 years after release (every year). Then, ring 3, the applications and development tools. They are updated from OBS, essentially rolling.
It would of course be possible to keep ring 3 also stable - for, say, 1 year. Update it when a new release comes out - you can keep the core and desktop from the previous version but have the new apps.

Split it up in components

As Robert proposed on the factory ML this week it would be possible to split openSUSE Factory not per-se in rings, but in smaller components, dictated by their dependencies. Some would be one package, others would be multiple. Each component is developed by a team in a factory-like model. Rob states: "Each component advances based on it's own release cycle and the component team decides which release of it's dependent components to build against. Some tooling will be needed to help sort out the combinatorial problem."

And "when a release approaches,the release team picks a version of the core component that will be the base for the next openSUSE release. This version is used to populate factory and may be the only component that is in factory for a little while." This scheme should make the job of the release team easier but would still allow us to release the same openSUSE. Perhaps faster, perhaps slower - or perhaps in pieces, giving users an unprecedented level of flexibility!

Core, selection + OBS

How about we take the core of openSUSE (ring 0 and 1 from Coolo?), add a few components which have a long-term commitment from their teams; and let OBS take care of the rest! So, we'd have, say, the Core, our default desktop with a base set of applications for it, LibreOffice and Firefox. That is the release. The rest you grab off of OBS. The core is maintained for a longer time (this very much depends on community input!) and much more tested than what we ship today.

To limit the impact of the change and for the convenience of our users, the installer would still be able to offer the same choices as it always has; but besides adding the packages, it also enables the repository they are found in!

Initially, the release would be a lot smaller than it is today - but in time, as people step up for long(er) term maintenance, it will grow again. The idea is similar to what was proposed on the factory ML this week, but might lead to less clashes between components as there are less of them (much is in the core, presumably).

The real discussion

The issue with all the above scenarios is that while we can technically do them (some are harder than others, of course) the choice doesn't just depend on what we can do but also on what we should do. That makes the discussion a lot more interesting. We have to fix some things in our process, adjust to reality, that is clear. But do we want to shift direction, too? What is our real goal?

Our previous strategy discussion hinted at the fact that most of our users are professionals, people used to computers. We decided not to focus on newbies and making things simple to the expense of flexibility of our distribution. Should we go further on that path, make harder choices to focus on people using computers for a living?

Conclusion

What I tried to illustrate with the 3 examples is that we can go in various directions. It will be up to some of our core developers as well as the dev teams to comment on what makes most sense, what is the least amount of work for the biggest benefit (to users). But there's also the question of who those users are!

oSC13, Strategy and Factory

The openSUSE conference had some chats about strategy. Ralf talked about suggestions from SUSE in his keynote and there were more suggestions discussed in person between various people. I'd like to summarize some of the things I heard. In this blog I will talk about the directions of Factory, what Ralf mentioned as SUSE's ideas from his keynote; later this week I will blog about the openSUSE releases.

This is a combination of stuff I heard (not just at oSC but also earlier - even from the first strategy discussion, 3 years ago) and ideas I have. I just attempt to put it into text so it is easier to shoot at, comment upon, think about.

Factory

Let's start with talking about Factory.

Who is it for

We need to think about who factory is for, how these people are supposed to be using it etcetera. Right now, we have a shared understanding - but it probably isn't always as shared as it seems and it can be good to write things down and talk about them (see my keynote at oSC). Some of these thoughts will come to the mailing lists, I am sure, over the coming months.

Where should it go

On the technical side, there are some things I've heard about and seen several times and which will most likely see some form of implementation:

• more automated testing - the openSUSE team did a openQA sprint but many agree that there is more room for improvement.
• getting more people involved - As Ralf said, SUSE will commit to more SLE engineers on openSUSE; and the community & the openSUSE team should work more on both growing our dev pool and training people. In a GSOC discussion about this at oSC, this point was made as well: it would be good to use GSOC also for bringing existing contributors to a higher level.
• Bringing Tumbleweed, Devel projects and Factory in alignment - As Ralf noted in his keynote, not all work on Devel projects and Tumbleweed benefits Factory and openSUSE ultimately - it would be great to unite forces and bring them all in one process!
• segmenting Factory in rings - which Coolo has been talking about for a while now. It would create a Ring 0 with the bootstrap- and compiler infrastructure, ring 1 with the base system and other rings on top of that. He has been experimenting with this, hinting at some results in this mail. I leave it up to a later post (perhaps by/with Coolo) to be more concrete about this whole thing once the core Factory team has talked to more people and expanded upon it...

That last point is by far the least concrete - it is an idea which is discussed and toyed with. How much and what exactly will happen - only the Geeko knows ;-)

Some discussion has started on the mailing list, by the way, with the idea of segmenting Factory in even more 'components' than just the rings. I had a chat with Coolo before this proposal came out and I suggested the same thing. He noted that it would lead to a huge mess of dependency issues, including many circular ones (he gave libpoppler as example). This is already brought into the discussion there, let's see where this goes!

On Innovation, Free Software, NIH, Geary, Trojita and KDE PIM

I argue that if Free Software wants to get anywhere, it needs a culture of 'collaboration first'. In most areas, we have that. In some, we don't - and that is hurting. The desktop is probably a prime example of that.

Rob Boudreau wrote an opinion piece about Personal Information Management (PIM) and the future. He concludes that 2013 has different requirements from PIM than 1995, and:

"KDE PIM seems to be the only FOSS project working on technology that will eventually go beyond just the PIM itself"

I think reality agrees with him. Mobile devices are cleverly integrating chat, email, social media and phone in one. Contacts have details on all of these and show the latest tweet or Facebook message of that person as status. Why doesn't the desktop do this? Well, it does, but only by putting your data on corporate servers, accessible though web browsers: Facebook, Google, Microsoft, ...

The Linux Desktop has a mission here: help keep user data out of the greedy hands of Google, Facebook and Microsofts! That can only be done by building on the shoulders of giants, not by re-inventing the wheel out of sheer arrogance. Let me explain what I mean.

Collaboration

10 years ago I often presented to people new to Free Software and how we work. I would explain the benefits of Open Source so:

"Imagine you thought of the best New Idea for word processing. From now on, documents will almost write themselves. But you first have to embark on the huge journey to write a full word processor. Three years later, your amazing application does not get anywhere as it can't open MS Word files."

"Imagine instead you added your amazing feature to an existing word processor. The discussion with the experienced word processor developers even resulted in a better result!"

Being able to stand on the shoulders of giants is an important benefit from collaboration in Free Software. We do have competing projects but note that most successful forks and rewrites were started due to a lack of collaboration! A recent example is LibreOffice. Often people from the 'original' project join or even start the fork or rewrite. Wayland is build by the Xorg team and the MySQL fork MariaDB is led by the founder of MySQL!

The Linux kernel is another great example. Google, for example, is putting in enormous resources in getting their technologies back into the kernel. After a period of forking for the benefit of speed and efficiency, they figured out that in the long run, it actually is more efficient to not fork and put in the extra effort in collaboration.

Collaboration-by-default is not a given. Aaron Seigo said about KDE:

"The open nature of the community has purged the “not invented here” syndrome from our ranks"

Yes, the KDE community has a strong tradition of re-using efforts and building on the shoulders of giants. And questioning those who don't! But such a culture took years to build as there is plenty reason to NOT collaborate.

Reasons for not collaborating

Failing forks or duplicating projects are often based on personal conflicts or a dislike for certain toolkits, languages or technical choices. And there is much starting from scratch because developers just focus on their own problem or want to learn something new.. While I would argue that you probably learn more working with experienced, competent people, and you might get more done, too, it is not hard to understand these reasons.

Then, there is psychology. Most people think they are smarter than average and programmers are no different (sometimes expressed as "what others do is easy")... Given the bell-curve followed by the distribution of intelligence, this clearly is one of the many fallacies our brain saddles us with. Even companies are affected. Google, working to get their features into the upstream kernel, discovered that not all the intelligent people in the world work for them and there is lots of room for improvements in what their team came up with.

More than one mail client

I argue that this last reason leads to more duplication of effort than healthy in the area of mail clients. Recently, Yorba pushed to get funding for Geary, another 'new approach to mail'. And there is Trojita, also providing a great IMAP client. Both projects were started in the last couple of years and seem to be re-inventing the wheel -- twice. As you probably saw many prominent developers giving a hard time to a company insisting upon writing another display server, I hope you understand how misguided I think this is. Yorba said they decided to write a new email client to keep things simple and fast and due to the complexity of other mail clients... I described the rationale and wrongness of this "let's write a new mail client" approach in a comment on LWN a while ago. In short, I'm betting that the reasons behind it boil down to the previously mentioned combination of over-estimating oneself and underestimating the problem. In the case of email probably a lack of ambition and forward-thinking as well. Just email doesn't cut it in 2013, certainly not 5 years from now.

Bringing conversation-view to email is an awesome idea - and can probably be done through a Google Summer of Code project within an existing client. Writing an entirely new email experience needs a bit more effort of course, but writing the entire underlying infrastructure too - that is just a sodding waste of time, pardon my French. Good to see Trojita at least has joined the KDE community and is working with KDE PIM! How about you, Geary?

More than one conference

I've always been a big proponent of the Desktop Summits and I do indeed think that it shows both arrogance and a lack of big-picture thinking that these don't happen anymore. I'm glad that the KDE board, including Agustin (who organized the first Desktop Summit) managed to kick off a "freedesktop summit" at the SUSE offices. I'm also glad that some people who DO see the benefit of collaboration participated there - even if their communities don't (yet) understand that it is worth the investment.

What we need

We need a culture where we are critical of people who don't try to work together or are unwilling to put in effort to collaborate. Free Software depends on collaboration and not working together is just counterproductive. So I'd like to ask all readers to support collaboration: talk about collaboration, share the tales of success. And if somebody decides to write an app from scratch, or is writing an application doing the same thing another does - question them, ask why they go it alone, why not collaborate. It is totally OK to be critical of forks and anti-collaborative behavior. You don't have to beat anyone up, but at least making them think about it is a good thing. And if you're a developer: integrate technologies, build re-usable libraries. And remember that the shoulders YOU are standing on can be made stronger for future generations of Libre developers! Just dumping disconnected code is NOT a contribution to Free Software, contrary to what some folks seem to think.

I'd also like to ask people to support KDE PIM: if we want to have a shot at keeping our data out of greedy corporate hands and if we want to ever get onto the corporate desktop, Akonadi is the only architecture that really has a shot. Instead of writing new wheels, let's improve this one together! Yes, KDE PIM needs UI work. Then why not do that? Writing a new mail client makes total sense - if you build it on a proper infrastructure. The KDE PIM team is greatly looking forward to help people who want to write new mail, RSS, Facebook or contact management applications. Skills required are mostly related to motivation and the willingness to ask questions and get help - otherwise, javascript coding skills will probably get you pretty far as it makes all the sense in the world to write these new UI's in QML.

Concluding

I'm happy to concede that things are not black and white. I'm sure nobody can fully judge neither Geary nor Trojita or all aspects of the Desktop Summit. Mea culpa for any wrongness. But please take the lesson to heart: there is great value in collaboration. And getting these benefits means putting in 'extra' efforts, yes, it can cost you something in the short run - that is the whole point of long-term vs short-term thinking. So, next time somebody argues that 'we can go faster if we do it alone', tell them that most smart people do NOT work for you and problems are always simple when they're not (yet) yours. Or just remind them that once upon a time, people thought volunteers could never write a encyclopedia. It is the 21st century and collaboration is what sets apart winners from losers.

Take care!

Dear KDE Community!

Dear KDE Community,

meet the mailing list where you can now talk about non-technical topics relevant to our community: kde-community. From a debate about our next conference to discussing our collaboration with other organizations and our goals as KDE community, this list is for anything which does not fit on the KDE development lists.

The goals are described clear enough:

The purpose of the mailing list is to provide a place for non-technical information and discussions which are relevant to the KDE community as a whole. All people who consider themselves to be part of the KDE community are invited to join. Conversations on the mailing list are respectful, considerate, polite and constructive following our KDE Code of Conduct.

The list collects announcements, information and results from discussions in other places and offers a place to get feedback on non-technical questions or plans of relevance for the whole KDE community.

As the 'collects announcements, ...' part already hints at, we expect people to try and make a habit of summarizing discussions which do NOT take place in public on this list once a conclusion is reached. This should be the central place for KDE governance debate.

You can find the list and subscribe here.

History lesson

Summer last year Cornelius wrote a blog about setting up a kde-community mailing list. It had been discussed on the KDE e.V. list that it doesn't make much sense that we have no public place to discuss governance related things in KDE.

Most of these discussions take place on the private KDE e.V. mailing list. Mirko Boehm proposed to simply open that list: what is discussed there is relevant to the whole KDE community. While there was agreement on the principle of opening up, there are things which are discussed there that probably should not be open. They are few and far between but some discussions about financial or personal matters do benefit from a less public place. Some argued that public discussions can also harm our public profile and it came up that bikeshedding could get even worse.

An alternative was proposed by Jos vd Oever: create a new list and put discussions there, unless there is a strong need of keeping them private.

After this, however, the discussion kind'a died out (I am summarizing more than a handful of mails here...). The subject came up at the e.V. board meeting in Berlin and we agreed that there's no good reason to Just Do It™. If nobody likes the idea the list will remain empty. Natural Selection FTW! I went ahead, asked our Amazing Admins to set me up, configured it and made Cornelius and myself admins who will exact our vengeance on everybody we disagree with who misbehaves.

So that's the story. The result is the KDE Community mailing list on the KDE servers. Is it official? What, you active in KDE and you don't know how nonsensical that question is? As always, the list will have to prove itself... I can only ask: please subscribe and bring your non-technical questions, comments, reminders and proposals to this list. We'll yell at the folks on the internal e.V. list if they bring things there which should be public.

And don't forget: if you want to talk to each other in person, this is where you do it. Go and book ;-)

Looking forward to your hugs at Akademy!