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!

Nextcloud is the future of open source file sync and share

So today is the day: we announce that we're forking ownCloud at some point the coming weeks. We includes project founder Frank and the core ownCloud contributors who publicly quit ownCloud, Inc. over the last weeks - Lukas, Arthur, Morris, Bjoern, Jan-Christoph and quite a few others as well who can't talk about that yet. As of now, most of the top contributors to ownCloud core are joining and of course, we're very busy hiring and aim to leave no (wo)man behind.

'why' is the question everybody has and I hope you understand I don't want to talk too much about that. Instead, let me talk about what we are going to do.

A healthy Nextcloud

Open source projects work best when they have a company behind them which aims to build a sustainable business around a symbiotic relationship with the community they are a part off. Make no mistake, I think it's great if people (investors, founders) can cash out big. They take a risk, put in blood, sweat and tears. But venture capital often leads to short term thinking and chasing of quarterly numbers resulting in bad decisions. Money, time and effort is wasted and growth isn't what it could be - and that's pretty much a best case scenario.

The good news is that we're starting a new company, Nextcloud, which will do things right: build a sustainable, durable business. We've got support from Niels Mache, long time open source entrepreneur and owner of the spreed video conferencing business. Nextcloud will integrate with spreed's successor, the open source, webRTC based spreed.me video conferencing software, kickstarting as a healthy, growing business with loads of customers while the integration provides a real valuable new feature to users.

What we will offer

This reboot of ownCloud is meant to be good for users, customers and contributors alike. So we'll be providing a drop-in replacement for users next month, which will bring them the stability and security updates they need as well as full spreed.ME video conferencing integration.

For customers, the drop-in replacement will be accompanied with a Enterprise Subscription which gives them all the support and features they are used to. Better, even: we will honor all contracts so nobody has to pay twice or get in trouble. On top of that we plan to support some of the most popular apps like Calendar and Contacts both for home users and enterprises. Our goal here is to ensure nobody is left without the support they need to be happy, successful own/Nextcloud users.

We're setting up infrastructure now for the wider contributor community to join us. We've got some improvements in store, including new forums (discourse based), no more Contributor License Agreement and a foundation that will hold trademarks (not have them sub-licensed; nor be under company control!). January last year we did a survey of what community contributors would like to see improved and, finally, we can implement many of those requests. I will blog more about that later today!

Future

I know that this is a surprise to everybody and it isn't that you should be joining RIGHT NOW or I'll hate you forever, on the contrary. ownCloud is a very important project and a rash decision makes no sense. We are in it for the long haul, our goal is a smooth transition and that means we will take some time to prepare things on our end. We've always been in close contact with our contributors and this new thing can only be open and public from now on so let's take our time to do this right. Over the coming days we'll blog about our plans and you can provide input and help us make the right decisions!

This endeavor will take some time and effort, but successful examples like LibreOffice and MariaDB have shown that, in the end, the community will find a way to get it right. I'm confident that we will be able to deliver even better solutions for our users and customers thanks to a redefined, more open community and company relationship!

Check out our announcement blog, our website and ping me or ask your questions in our Live Nextcloud Q&A Hangout with Frank and myself, moderated by Bryan Lunduke, today at 19:00 PM Berlin/Amsterdam/Paris time, 10:00 AM Pacific time.

And yes, if you want to join us, send an email, we're hiring!

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

I'll be at SCALE and FOSDEM, how about you?

Next week, the Fourteenth Annual Southern California Linux Expo kicks off in Pasadena, LA. A week later it's FOSDEM time, in Brussels, Belgium. Both events have a ownCloud booth and a KDE booth, and both can use some help! More importantly, I have to tell you why you should bother.

  

Helping at a Booth

You might read this (and other blogs asking for help at a booth) thinking

"why the heck would I bother"

or

"why me, I've never done this before"

It seems, perhaps, a crazy tiring and difficult thing to do, standing at a booth and talking to people all day. Coding beats it any time, you'd think. Well, believe me: reality could surprise you!

Let me ask first:

Have you ever visited a geek conference like FOSDEM, SCALE, or something smaller, locally?

If not, let me tell you - it is a blast. Interesting technology but more importantly - interesting people. Often, you can talk to the people who "do the work" and believe me, they have things to say.

"Conferences are like rock concerts: the back stage experience is THE BEST"

But let me tell you a secret. Conferences are like rock concerts: the back stage experience is THE BEST. Seriously, being part of the booth team adds a whole extra dimension to the experience. First, because you get to talk far more intensely with the rest of the team - you'll be there setting up the booth, having breakfast in the morning and beers together at night, plain awesome. But don't discount the visitors. Many have interesting questions and stories to tell and the conversations can be fascinating.

The Good Stuff

Now you might say:

"but it is hard work, right, with hard questions to answer? And all I get is a free entree ticket..."

Yeah, true on the ticket. And you might not be a huge fan of people and talking in the first place, perhaps, I get that, too.

But you're still wrong about it. You see, these conversations aren't like a typical birthday party chit-chat where you have to explain (again) what you do, be nice and social to your aunts you don't like and all that. Nor is it like the pressure of a business meeting, or a networking session. It is nothing like that!

It is hard to explain, but let me try. It is more like trying to help that colleague who recently joined and just doesn't know the product very well. See, people are almost always nice, interested and just as geeky as you. You might not know the but it isn't about that: they don't really talk to "you" but to "KDE" or "ownCloud". Even if you're not naturally a speaker or enthusiastic, the conversations are very easy. As a matter of fact, after having had five, you'll notice four of those went almost exactly the same and you'll develop a kind of elevator pitch, not the fancy ones, but the ones you just naturally assume. Believe me, before you know it, you'll be approaching people who haven't asked a question yet and ask if you can help them.

"Some visitors can be best described with words usually bleeped out on TV."

The difficult people

Of course I won't claim it is all, always easy. Sometimes, visitors can be described with words usually bleeped out on television. I won't lie to you. But even this isn't too hard to handle. First, because you don't write all of the code in your project, or even none in many cases (like mine). You don't have to take it personally. Plus, realize that, in most cases, those being difficult do it because they care: they wish the project was more, better than it is - that happens to be a wish you share with them. Often it just isn't meant half as bad as it might have sounded and a quick conversation shows the common ground. Moreover, you are not alone. You have your team mates to back you up (or complain to after the visitor left) and hey, that's just bonding, right there!

I think that without the few bad conversations, the really good ones wouldn't stand out as much. Yes, there are really nice, energizing conversations. From people who just come by the booth to tell you how much your project (and by extension you) rock to people who tell you, sometimes to the point of really getting emotional, how your community has provided them with something amazing. At those moments, you just soak in the love. Be sure to record or note down any concrete compliments so you can share this later with the community online, in a blog or just a mail to the development mailing list!

If you want to learn more, I've been writing a how-to on organizing a booth and collected some practical tips for conversations with the visitors on this page. More tips welcome!

Now, how can you help?

KDE

The KDE booth at SCALE is actually a bit in trouble. We have some folks who have been helping out the last few years but, perhaps in part due to the early dates, just couldn't make it this year. If you're a KDE user, contributor or just fan, think about helping out! If you use KDE software, especially Plasma of course, and occasionally follow the blogs, you'll have what it takes to help out. Most questions are basic and there are always others around who can help out a bit here or there - including myself, I'll check in a few times for sure. And the openSUSE booth next door, which helps organize the KDE and GNOME presence at SCALE, has plenty of experts in all areas as well. You won't be without backup, not at all!

KDE at FOSDEM already has six volunteers (see the wiki page) and we unfortunately only have one table this year. While help is always welcome, this ain't super urgent. It IS fun, though, so if you're up for it, give it a try!

ownCloud

Matt McGraw and myself will staff the ownCloud booth at SCALE, ready to answer any questions you might have. We're just with two people, so we'd sure welcome a third person! If you're interested, just shoot me an email or comment here. It isn't difficult - I'd even say that if you've been using ownCloud for a few months you can already provide a lot of help at the booth, and Matt and myself are always there.

At FOSDEM, we have a few more volunteers but I also know, from last year, that the booth will be flooded with visitors so if you're up for helping out, even if it's just a few hours, please let me know!

I hope to see you at one or both of these events and that I've motivated you to help run a booth ;-)

Lightning Fast

For the last two years, we had only lightning talks & workshops at the ownCloud Contributor Conference. This is an exceptionally good model for creation-type events like ours and your event might benefit from it, too.

Why

To find the best way of presenting content to visitors you must define goals for an event. If your event focuses on creating, building, developing or making and collaboration between participants who might not know each other yet is important, a track of lightning talks is a great way to kick off.

What

Lightning talks are very short sessions (3-15 minutes, usually gravitating around 5 minutes) which are typically scheduled in a single track. This means that the entire audience of an event is in the room and explains why the talks have to be short. Even if some of the subjects aren't interesting for everybody, the next comes in just a few minutes.

These talks provide an opportunity for people to present what they work on and for the audience to find out what is going happening in the project. Perhaps more importantly, the audience can find out who to talk to - connecting names and faces to subjects.

Indeed, due to their nature, lightning talks do not go very deep. This is as much a strength as it is a weakness, though, as presenters are forced to get rid of most of the content so they focus on what matters most. Overhead like lengthy personal introductions, many examples or the setup of demos falls to the wayside and a single point emerges.

How

As the format is a little more unforgiving than 30 or 60 minute 'tech talks', it is a good idea to practice in advance. Luckily, the short duration means that rehearsing the talk 5 or 6 times isn't a big time drain.

For the organization of an event it is important to get the slides from the participants well in advance. This not only forces the participants to be prepared but, as there is no time to even switch presentation files, you can prepare them in a single go. I demand slides in PDF and concatenate them in a single file.

To keep the audience hooked, schedule the lightning talks with much variation. Vary technical subjects with process-oriented talks and social ones. Look for a light note occasionally and be sure not to push to many down the throat of the visitors without an occasional break. In that time, people can look up the presenters and dig a little deeper, process the inspiration and relate it to their own interests.

It also makes sense to have them in the morning and/or the first day, so they provide a starting point for, especially, new participants. They can set the tone, perhaps not like a keynote does, but more practical.

If you additionally need more in-depth sessions and technical talks, you can schedule them in parallel after the lightning talks. This also gives speakers in the lightning talks the opportunity to invite people to these sessions, giving participants some insight in what they will cover.

My personal todo for the next #ownCloudConf includes practicing all lightning talks with all speakers in a one-on-one video call, both to solidify the deadline and increase quality.

Why open source works

Trying to explain why open source works, you can of course point to the Cathedral and the Bazaar by Erik. But the kernel development process shows it happening 'in real time', every day, and that's a major reason why I so enjoy reading the weekly LWN.

Competition FTW

A recent article explained how two patch sets are developed, impacting the Huge TLB feature. One is about improving reference counting in the handling of huge pages to allow a huge page to be mapped in both 'huge page mode' and in 'normal page mode' by different processes. This is a first step towards being able to use transparent huge pages with the page cache, giving it access to the performance benefits of huge pages. This has been in the works for a while as it is a very complex change. But an alternative has recently surfaced, adding transparent huge page support to the tmpfs filesystem. This also has pieces needed to support huge pages in the page cache, but in a very different way.

Why on earth would you want developers to spend so much time on two competing solutions for a problem? Isn't there One to Rule Them All?

Finding that perfect solution

I am sure that there is a Perfect Solution. I would simply suggest that nobody knows it! Like in economics, where an equilibrium exists but no single person can define it, software development has become complicated enough that competition of ideas often leads to the best (or at least better) solutions.

Companies, building their own cathedral in-house, would put product managers and developers in a room. Let them come up with the Perfect Solution. But they won't, because of Joy's law:

"No matter who you are, most of the smartest people work for someone else"

Impressive results

This is the key to why open source works and works so well. No single development project in the world even approaches the size of the Linux kernel project - no less than 1400 people contributed in under six weeks. With millions of lines of code developed by tens of thousands of people over 20 years time and with an extremist attitude towards backwards compatibility, you wouldn't expect the trend to be "go faster". It is.

Bringing over almost 12,000 different people from 1,200 different companies together in the last decade, the kernel competes with Wikipedia for the title of humanity's largest collaborative effort. Oh, and I'm sure the masses building the pyramids were big, too, they just didn't integrate the experience of all their collaborators into its architecture as well as the kernel and Wikipedia do ;-)

Cookie licking

Many other projects struggle to learn from the kernel's success. Success which has many aspects, one of which exemplified here, a rule Frank sometimes talks about: no cookie licking!

In short, cookie liking is preventing others from working on something by claiming you are (but not really making progress). Extending it a bit, I would say that, while collaboration is good, if you feel you can do better -- or just want to sample a different approach:

"never be deterred to build an alternative solution to a problem"

Because it's space for competition within projects that makes open source work better.

Open Governance Update

About 18 months ago, I put together a presentation on open governance for the Summit of New Thinking.

Last week, as a side event to LinuxTag, the European Community Leadership Summit took place, co-organized by +ben van 't ende, a friend of mine and fellow community manager. +Mirko Boehm and myself gave a talk about community governance. I unfortunately couldn't stay long enough to have proper discussions on the subject, but the presentations before and after ours were very inspiring (especially the one by +Ruth Cheesley).

A nice thing which came out of it for me was the notion that instead of 'rules' one should try to work with 'expectations'. Of course, it is 'just language' but the effect of that can be immense. Perhaps I should re-think my entire 'open governance' presentation ;-)

In any case, if you'd like to see the slides, they are here. Yes, I have a self-signed certificate. No, that doesn't mean my ownCloud is evil, you can trust me! (really)

The slides are probably not terribly useful on their own, though.

Meta Blogging

Today, I blog about blogging. My goal is to convince you, hard working contributor to KDE, ownCloud or openSUSE, that you should regularly blog about the awesome you do.

Blogging is great

Contributors blogging about what they do is awesome, really. This way, we:

• Share knowledge so others don't have to re-invent the wheel
• Share ideas so others know what we're up to and can help improve plans
• Get help so readers might feel compelled to help out!
• Give help so using ownCloud/KDE/openSUSE/etc becomes easier for people
• Increase our visibility so users/developers know who to beat up talk to
• Create some noise for the outside forums, news sites, magazines etc - press in general

And that's all absolutely awesome. I even bet there are at least 3 more reasons why blogging is good for your community and I hereby offer cookies for whoever shares three other reasons in the comments section.

But let's be honest. Who cares about how it benefits whatever? It's the age of me me and more me!

But what really matters...

So I want to make clear that YOU benefit. Taking time off to write down what you're working on, putting ideas in order—this is incredibly useful. You will not only become a better writer but also a better thinker. Better at expressing your ideas but also better at putting them in order, examining them, refining them.

Blogging makes you stop and think about what you are doing. You take a little time to dive a bit deeper in what drives you, why you work on what you work on and how you can do better.

This should make clear that the idea of "I have nothing to say" makes no sense. If you are doing things, you must be thinking about them. Blogging is just thinking out loud. Which helps YOU think and, as I pointed out above, helps others see what you think about and give you input.

HOW to do it then?

I'm not going to say writing is simple. If you look up the first posts on my blog, well, let's just say it didn't come by itself for me either. You might be looking at a blank page for a while. But it gets easy when you have something to say! If you're enthusiastic about something or pondering a complicated problem, that is the moment to start. Open your favorite text editor and just blurt down your thoughts, why you're happy/angry/enthusiastic/etc.

Then structure it a bit, try to explain the things. You might have learned this in the past already: explaining something complicated to somebody else is awesome, because you learn from doing that yourself. Maybe even more than the person you're explaining to!
Then make it more presentable. Add a few headers above big paragraphs to break it up, maybe add a picture. Flickr is a great source of pics and it makes your blog a bit lighter, but it is not mandatory at all. Then just publish. Because, really, you can polish forever but it will never be perfect. And you learn while writing. So write, publish, and write some more!

On the idea of "you must do regular writing": a myth. Yes, writing about what you did last week is helpful. It gives a base to start with, keeps your life organized. But it is not The Only Way To Success when it comes to blogging. You need a bit of inspiration. I've gone months without blogs, and had weeks with several. That might not be awesome from a 'social media' perspective but really, who gives a rats' ass about that? I know I don't.

Write when you are thinking about something, when you're inspired. That's enough.

Conclusion

Blogging is helpful. Most people don't feel compelled to share their expertise, knowledge and ideas. That is OK, of course - but if you are willing to blog, please do it! It isn't as hard as it sometimes feels and it is more helpful for yourself than you might think.

And if your project has a blog roll like planet KDE, planet openSUSE and ownCloud News, get your blog on there! More readers = more comments = more motivation and more value for you. Really!

For the ownCloud folk: contact me if you want your blog on our blog roll. I'd be happy to add it!

oSC14 and LinuxTag coming!

It's becoming conference season again... Tomorrow morning I'll fly to Dubrovnik for the openSUSE Conference. I give no less than 5 talks and one workshop. Don't worry, I'm not DDOSing the event, the talks are restricted to 30 minutes (even though I have about 1 hour of content for each, let's see how that goes). My sessions:

• Social skills for geeks
• Presenting awesome (workshop about giving presentations)
• How to run a booth and present your project
• Where KDE is and where it is going
• Cloudy experiences at home (about ownCloud!)
• Community building in 10 steps

That's quite a bunch, I know, but it'll be fun! I look forward to Dubrovnik, although I see it will be rainy and not that warm. Ah, sad...

LinuxTag 2014 - all change

A much bigger deal, for me, is LinuxTag. This year, it is considerably different from the previous few years: no more in the Messe! Instead, the team is collaborating with DroidCon and Re:Publica. That, combined with the location (Station in Berlin), could potentially be awesome! Here I give one talk about the future of KDE. I'll also be speaking at the Community Leadership Summit Europe about Open Governance.

But more importantly, I'll be organizing the LT booth for three projects: ownCloud, KDE and openSUSE. Yeah, ambitious again! Not only that, we're not going for the traditional booth. Instead, I've proposed to do something different: have a track of technical mini-workshops at the booth. 45 minute talks, small, hands-on, about the technology of these projects. So, think about building packages with the Open Build Service, writing an ownCloud App or developing a QML based Plasma widget.

Needing some help

The idea seems generally liked but I haven't found anybody for any of the three above potential talks - so if you can and want to do that or something like it, please let me know! We won't have too much traditional booth space, just enough for a bit of stuff and one or two ppl answering questions. The talks will repeat every day so as volunteer, you give your talk 3 times, once every day. Otherwise you are free to enjoy the talks as well as the Re:Publica booth area. As the tickets are not cheap (Eur 149!) this is a nice way to get into LinuxTag for free (I have only 2 tickets per booth, though). You'll get hugs and Club Mate as much as you want. And there's travel support available for all these projects!

Help me out, please! And if you can't - at least, be sure to visit the booth at LinuxTag or come say hi at the openSUSE Conference!

Leaving SUSE

Dear Geekos,

I'll be leaving SUSE by the end of this month.

What that means

That does not mean I am running away from all things green, I still have no less than 5 talks to give at the openSUSE conference and I will certainly continue to put in some spare time for the marketing of oSC14 and news.opensuse.org! But it won't be a full time contribution anymore.

Now I know there have been some heavy discussions lately about where we as openSUSE community are going and despite the rather rough start, I think we are on the right track now. The openSUSE Team is hacking on OBS, openQA and other tools and that will help improve both the quality of openSUSE as a distro. I also think the new board is great and will make a difference on the community side.

You all rock!

My time at SUSE has been amazing. You, the openSUSE community, are awesome, smart, sweet and fun. openSUSE as a distro is kick-ass, OBS rocks and so on. I'm proud to be a part of the Geeko crowd and be allowed to make my modest contribution. And it was great meet you at events and conferences around the world!

You might wonder where I'm going - well, I have to keep that under wraps until the end of this month. But I'm not leaving Free and Open Source behind and I'll still run openSUSE!

See you later, Geekonator...


PS: In the spirit of my cat presentations, let me finish this post with a pair of cute eyes from our dog Popcorn...

Giving constructive feedback

Feedback is often equated to 'yelling'. But it doesn't have to be - feedback is, after all, central to learning. And in Free Software, where learning is a major motivation for many participants, proper feedback is very important.



Many of you have seen how Linus can yell at people and unfortunately, some mistake that for effective communication. It is not. But what DOES constitute effective feedback?

Three Rules

Plenty of books have been written on the subject. To save you the reading effort, I'll summarize the most important lessons here: three rules for how to give constructive feedback.

RULE 1: find the right time and place (or don't do it at all)

Both you and the other person should be in the right place, mentally and physically, for the feedback. For example, don't embarrass a person in front of a crowd. Feedback is best given in private, unless of course it is explicitly asked for in a group. But even then, think about what you say.

And have the right attitude towards whatever has to change: everybody makes mistakes. Constructive feedback should be building up, not breaking down. None of us is born as a super coder, we all had to learn. If you and/or the other person are angry, it will be a shouting match. If there is no way for the other person to improve, why frustrate him or her with feedback?

The time element is crucial as well. Feedback should be timely: giving feedback on an event that took place weeks ago, most likely long forgotten by the subject, offers little value. Be sure you have a certain event or action in mind and can be specific about when, where, who was involved and what the results were.

Rule 2: Describe, don't judge or infer

Most important, constructive feedback has to focus on the facts of behavior in a concrete case. And on its consequences, not on the person and who they are. That sounds easier than it is. It is best to follow this format when giving feedback:

• describe the specific behavior/action/code itself
• describe how it made YOU feel (emotional feedback) or the effect it has on $SUBJECT (technical)

To focus on behavior use adverbs to describe action, rather than adjectives describing qualities. Help the other person understand the impact their actions have.

Let me give some examples:

• unhelpful: "You were really an asshole in the meeting today" -> personal and pretty darn judging
• unhelpful: "You were trying to derail the discussion! -> inferring goals
• helpful: "When you talked so loudly during the discussion you made me feel really anxious"
• unhelpful: "Your patch sucks" -> not concrete
• helpful: "If you write code like $EXAMPLE you will break $DESIRED_BEHAVIOR"
• unhelpful: "You always forget to add comments to the code!" -> generalization
• helpful: "Yesterday when you checked in the code for X, you did not add comments in $FILE, so it took me a while to figure out how it did fit in"

This also works with compliments:

• unhelpful: "You're a great coder!" -> unspecific
• helpful: "When you commented the code with that high level overview you made it easy to understand the flow of the class"

Negative feedback which is too vague just frustrates: there is nothing to improve. But unspecific positive feedback is not that great either: people frequently doubt your motives ("Is she trying to get something from me?") and it even makes some people feel insecure.

Note that when giving feedback, people have a tendency to emphasize or even exaggerate. Feedback tends to land much harder than you think, even with people who seem impervious to criticism. It's better to bring it softly and remind people later then to lay it on heavy and make them feel inadequate or not appreciated.

Rule 3: Sandwich it

It matters how you introduce the feedback. If you weren't asked for it, note clearly that you'd like to give some feedback. Perhaps this is a bad time - allow the other to point that out and if so, just let it go.

Then, seek for balance. Certainly there are things to improve, but there is always something that was done well. We tend to focus on the negative. To prevent that, 'sandwich' the negative part with positive feedback: start with something that went well, follow with the part that needs improvement, finish with another part that went well or a silver lining. Not only does this help digest the feedback better, it tends to force you to think about it more as well.

If you can, try to give some tips or hints on how to improve. Share how you dealt with this issue in the past, perhaps. Here, too, be as concrete as you can.

After giving the feedback, let the other talk. It is not unlikely that the recipient will act defensive. Don't take that as meaning the message did not land - most people have trouble admitting mistakes when confronted with them, even if they are brought the Right Way™. Let them respond, say you understand - most importantly, don't pile up more 'evidence'. You've done what you can, it is now their responsibility to take it - or not. If you get no response you might want to ask a open question like: "What do you think".

Note that you can give too much feedback. Improving oneself is a lot of hard work - and one can work only on so many things at once! Recognize progress, even when it is slow, and leave room for mistakes. If a colleague tends to make certain typical mistakes you don't always have to point them out. Give him or her time and opportunity to self-correct, silently accept some of the mistakes and space out the feedback a little.

Feedback 101

There's something to receiving feedback, too, of course. Note that following the rules above isn't always easy and sometimes people are frustrated and do yell. Try not to get angry - feedback, any kind, can help you improve. Even if it is not brought to you in a nice way.

Giving and taking constructive feedback is a hugely useful skill to have - it helps you as well as others to learn and get better. And while most of our communication takes place online, these rules apply as much if not more so. Thanking somebody for a patch, starting by commenting on the good side of it, before you hack and slash in on the less-than-great parts, adding concrete ideas for improvements, and finishing with a high-note in proper sandwich style: it can make the difference between getting an improved patch or never hearing from the contributor again.

If you have comments, feel free to share them ;-)

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!

Getting involved in Free Software

I frequently get the question, by mail or over social networks:

But how do I get involved in $PROJECT?

Now a common answer is 'just do it' while others often point to resources like the KDE Developers Beginners Guide and Contribute to openSUSE, or write a simple how-to for building a package. But I usually don't actually reply with links to any of those. Mostly, people have found these resources by themselves.

What they want to know now is how to, you know, actually do it! And as that question can actually be answered rather project-independent so I thought it would be useful to write it down here.

Step one - Build the Code and get Familiar

After reading the various guides and how-to's, you set up a development environment. Be sure you can run the unstable application(s) or hack on a package. Getting that up and running is a very good first step.

I would also subscribe to mailing lists, read the blogs and hang out in IRC. Just watch what is going on: it will teach you the culture of the community and that's crucial to get stuff done later.

Step Two - Hack Something

Perhaps you will already find bugs, then: trying to report them is good, trying to fix them is better. It will not be easy to fix them but that is when you can ask for help on IRC, forums or here!

If you don't find any bugs you want to fix, perhaps you can think about what to add, what to change. What do YOU think is important and what needs to be done? It doesn't matter if you pick something yourself or find a todo list or wiki page of the project and pick something there. The hardest part will be: JUST DO IT. Get hacking. You'll get stuck, that is OK: read documentation and when you can't figure it out, just ask for help. Above all: don't give up until you are done! I would suggest not to pick something too big. A one-liner patch will take you a day, easily, and might not seem important, but this first step matters a lot. Don't try to fix the entire user interface or work flow with your first change! For example, fixing code style to comply with the project rules is already a perfectly fine first step.

Step Three - Get it in

Now you got something, so get it back to the project. On Github or on the Open Build Service you do a merge request; in other projects you have different work flows varying from sending the patch by mail to using review board or other tools. It doesn't matter.

This won't be easy, but that is mostly due to you being so anxious about it: it can take quite a while for the developers to review the patch and they're sure to have some comments on it. Don't be discouraged and do know that you're allowed to poke them: two weeks waiting isn't much in many projects but it's enough that you are entitled to poke somebody. Send a follow-up mail or ping somebody you know is active in the project on IRC and ask politely if they know how you can get feedback or if you did something wrong in the way you asked.

Note that your patch will not always go in, even in modified form. Not all projects might be OK receiving code style fixes or consider what you fixed a bug. Again, the hardest part here is to not be discouraged. You can ask if they can at least tell you that what you did made some kind of sense; and/or ask for a suggestion for something easy to fix. If they're half-way decent they will be nice about it! If not, perhaps you picked the wrong community to help out in...

Step Four - That's all!

When you manage to fix or hack ONE thing, you have done the hardest part of getting involved in Free Software: you GOT STARTED. From then on, you can find other things and really Make a Difference.

Really

Seriously, there is no more to it. The hardest part is of course the doing itself - but no amount of preparation can make that easier. The most important tip in this is to not give up, the second most important one is to ask for help. All developers had to go through this. Some locked themselves up in a basement, others spend a week banging their head against a computer screen. All of them created a ugly beast of a patch, article, image or whatever your first attempt is. That is perfectly fine. Accepting that is probably the third most important tip ;-)

Of course, I can recommend to check out Open Advice as it contains the lessons of quite a few smart folk. The short essays make for a nice read before bed time or so.

Have a lot of fun and enjoy hacking ;-)

Consensus decision making

Jono blogged about respect in community discussions. I have zero to say on the storm-in-a-teacup (his words) that started it other than, perhaps, suggest that when there are waves, there is wind. But whatever direction that wind blows, I'd like to focus on something else. Jono made the following statement:

Ubuntu is not a consensus-based community. Consensus communities rarely work, and I am not aware of any Open Source project that bases their work on wider consensus in the community.

I'm not entirely sure what he means with consensus and community here. He himself defines community as "a collection of people (or animals) who interact with one another in the same environment". Consensus decision making, according to Wikipedia, is:

"a group decision making process that seeks the consent of all participants. Consensus may be defined professionally as an acceptable resolution, one that can be supported, even if not the "favourite" of each individual"

Talking consensus

Let me take this as an opportunity to address a common misconception about consensus: that consensus means full agreement. The Wikipedia entry already points out that the outcome has to be 'acceptable', one that 'can be supported'. This matters: Jono probably meant to say that there is no sizeable community where everybody fully agrees on every decision and I can't imagine he is wrong on that. But that is not what consensus means.

(dis)agreement

The reality is that in a large and diverse group of people, it is impossible to really reach full agreement on any sufficiently complicated matter. Making decisions on agreement of all participants thus doesn't work. Consensus, instead, allows a decision to be made even in the face of disagreement. Essentially, it is a form of democracy without voting.

Ever heard the phrase: "Let's agree to disagree"? That is it: at some point in a decision making process, consensus requires some of the participants to be mature enough to step out of the way and let a decision actually get made. And others need to respect them for that.

Voluntairy

What makes consensus different from voting?

Usually, those in a small minority are the ones who have to (wo)man up and accept that the decision and project is more important than them. The main difference between voting however, where minorities (anything below 50%, usually) don't get their way, is that it is not mandatory. In some cases, the minority can get their way and it can be the majority which steps back and lets them. And even if that doesn't happen, the difference between being forcefully over-ruled and gracefully accepting that you can't always win is big.

A second key point is that ruling by consensus requires discussion, much more than voting does. You can't make decisions by consensus without informing people of the choices - you have to know what you (dis)agree with. Certainly, a community where a few take decisions without talking about it does not decide based on consensus.

Last, the two are not incompattible. It makes all the sense in the world to occasionally do an 'opinion poll' (as opposed to doing a decisive vote) to aid the decision making process. This is valuable input for a consensual decision: vocal supporters of either side can create rather distorted views on how strong the support for a certain opinion really is.

Trust and respect

So I think Jono is wrong when he states that there are no communities which decide based on consensus - KDE is an example of one, Gnome does it often and it's pretty much the way of the Geeko, too. Others usually prefer to vote (Debian) or have a more top-down structure like Ubuntu. There are many ways to Rome, as they say. Being aware of that is a good thing - and being dismissive of ways other than yours is not.

I want to add that Valerie Zimmerman made an excellent argument for the importance of trust and respect. No structure of decision making works without these - trust that those who disagree will have the courage to agree-to-disagree, trust that the majority is right or trust that those who decide for you make the right decisions. And respect each other while debating it.

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!