openSUSE at LinuxTag 2013

As I wrote last week, openSUSE was at Linuxtag. We didn't have a huge team like last year, nor did we bring all the beer - but we had some fun nonetheless.

Awesomeness

For me, the most awesome thing was the openSUSE Jeopardy done by Christan Boltz, it was SUPER cool. Of course, part of that was because I won, mainly due to the quotes section - my fellow participants had no idea who wrote them. I even recognized my own quote and it looks like I still can agree with myself. Must say that the Jeopardy thing was really, really fun.

For those wondering what the heck I'm talking about: we have small booth talks at our booth at LinuxTag. I believe Henne Vogelsang once started doing this (even before I joined openSUSE), teaching people how to fold paper Geekos and stuff like that. I'm not that creative, so I only gave KDE tips and Tricks on Wednesday and Saturday. Strange enough, nobody even seemed to have noticed that I gave that session in my favorite GNOME shirt... Luckily Christian had a way better idea for these booth talks: Jeopardy!

He has a cool html web thingy for it, complete with tracking scores and all that and I had arranged Club Mate for the winners (and, often, for the losers too). There were questions in areas like security, coding and development languages. Some worked with pictures, others had text but they were all quite ingenious. The '/etc/firstline' was cool although I didn't know any of them: it shows you the first non-comment line of a random file in /etc and you have to say what file it's from. Many of the questions were rather not openSUSE-specific, only the quotes from the Factory mailinglist (quote, you guess who said it) and the openSUSE Releases (screenshots of openSUSE login screens, you guess the version) were. I even learned a thing or two ;-)

Bernhard Wiedemann also joined the booth team, I even have to say he formed the core of it, being the most steady force as Christian didn't make it on Wednesday and I wasn't there on Thursday and Friday. He talked about OBS packaging which also attracted people interested in packaging.

The booth

Meanwhile, I've been working on the new openSUSE Merchandising program and that includes making a 'list of stuff to bring'. I decided to try and use LinuxTag to test out a few things! The booth pictures you see include some (but not all) of the goodies we plan on including in booth boxes. We learned some valuable lessons about the materials at the event. Our booth was at the entry of the event, for good or bad. The area was a bit small (although we shared some space with the ownCloud team next to us) but mostly people simply walked by to the main hall with booths and I'm not sure if they ever came back...

We had no beer this year but openSUSE Conference flyers and posters as well as a batch of 500 openSUSE flyers based on a design we've been working on in the last 2 years (until now they were only printed in the US). It seems not too many are interested in going to Greece (can't imagine why) but it was still good to point the existence of the conference out to people.

For the openSUSE flyer I had the explicit goal of seeing if it could help kickstart a conversation. I am not sure if that really works, but of course our booth team was so experienced they don't really need talking points.

The 'we believe' poster got some very valid criticism from the ownCloud team which was next to our booth: it has too much text on it and people simply won't read it. Having that design as small (a6 or so) hand out might work far better, or as a slide in a presentation. And having a big one with images or somehow else more, hum, easily (lazily) processed might be a good combination. Anybody has any ideas on how to put our philosophy as expressed on this poster in the form of a more graphical image? I'd love to see some ideas ;-)

Also, if you visited our booth and are reading this - I would love feedback, both good and bad. On the looks of it, the posters, flyers, DVD, people - all of it!

Talks

We also had a few 'big' (as in, not at the booth) talks. Bernhard and Sascha spoke about OpenStack / SUSE Cloud / crowbar in the main track and I myself talked for about 30 min on what happened to openSUSE in the last year and gave a 2 minute lightning talk about our booth as well. All talks went well but LinuxTag isn't the most crowded event and seems to be getting smaller - talking for 20 people is perhaps more fun as you get to have more close contact to the audience but it's hardly worth traveling for.

The booth talks I gave about 'advanced KDE usage' where big fun. They usually had just a handful of visitors which meant we all sat together around my laptop and could discuss things quite nicely. Fun!

Edit: and I forgot to mention the talk Bernhard gave on "openSUSE on ARM" including our cross-compilation tricks with qemu-linux-user. And sorry for the appearance of some old blogs on planet.KDE, I have no idea how to convince blogger not to do that stupid thing - I only updated the tags. The dates are correct :(

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

LinuxTag Awesomeness!

Heya,

Tomorrow LinuxTag starts again. There'll be an openSUSE booth, although we won't be overstaffed this year. If you're up for helping, that would be greatly appreciated. You don't have to be a super technical person to be at a booth and help out: if you follow some blogs around openSUSE you already know more than most visitors and you can help out just fine! It's how I got started...

See you at LinuxTag! You can find us Geekos at Hall 7.1a, Booth 130.

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.

Building for your version of openSUSE in 5 simple steps!

Today I bumped into a blog about dfc, a more fancy version of the df command. There were instructions on installation for Arch and an older Ubuntu version - a link to software.opensuse.org/package/dfc wasn't there but easily found.

There were packages, thanks to the awesome Open Build Service packagers. Unfortunately, it wasn't build for 12.3 yet. Now what? Luckily, this is what OBS makes easier than pie, let me show you how you can build this package for YOUR openSUSE version without ANY technical knowledge!



Step one, you click on the repository name, "home:tcpip4000". You now go to the OBS page where Juan "tcpip4000" Danza builds dfc. In order to be able to make changes, we need to branch dfc into our own home (you need to log in on OBS first to do this).



Step two, you click on "Branch Package" and say OK to the question if you're sure about this. Now, you've got dfc in your own home and the Open Build Service will immediately begin building it. However, it still just builds for the operating systems tcpip4000 had defined - we have to add a new one!



Step three, click on "repositories" and change them. You'll see on that page you first have to go to the project that dfc is a part off, as you can only enable or disable building for a package, not the build targets themselves. Click on the branch ("home:jospoortvliet:branches:home:tcpip4000") and under "Repositories" there, you pick "Add repositories".





Step 4, you can pick what you want and hit the button on the bottom of the page to add them. By default, packages are build but not 'published' in a repository for easy download. You can change that by hovering over the "Publish Flag" section and enabling the publishing.



Step 5, go back to the dfc package which will be build by the Open Build Service and then published in the repository. You can use the little refresh button to check for the status - and once it is build successfully, click the download button and call it a success!





Now, enjoy your new package and have a lot of fun!

If you want dfc for openSUSE 12.3 and Factory, check here. Of course, not all packages will build successfully for a newer or older version of openSUSE: you might have to make changes to the spec file. That is where things get more complicated and you'll need the documentation on packaging and help on IRC. Also, if you're up for it, this can all be done even faster from the command prompt with a few simple commands. But that's a lesson for another day ;-)


To add one more DFC tip: if you edit the .bashrc file in your home folder, you can use this command by default. I have this in my bashrc:
alias df='df -h' # human-readable sizes
[ -f /usr/bin/dfc ] && alias df='dfc -T' # use dfc if there for prettier df info and show filesystems

This will ensure that if you have dfc installed, it uses it by default (the [ -f ] thing checks for that) and if you don't have it, df -h will show the output in human-friendly sizes :D

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!

Why should you participate in GSOC as mentor?

When deciding about participation in the Google Summer of Code program you think about the opportunities of getting new people involved or code written versus the time they have to put into mentoring and evaluating. But there are other, often overlooked advantages to participating in GSOC and I'd like to point a few of those out.

GSOC
Google started the hugely successful Google Summer of Code project in 2005 to get students exposed to 'real developers' and open source. Since then, it has allowed projects to mentor thousands of students who were enabled to work on Free Software full-time thanks to the payments by Google. Conceived of by Sergey Brin and Larry Page, the project was also supposed to bring fun, excitement and innovation to the open source community. Each year, thousands of students send in proposals and Google allows the most promising of them to execute their ideas.

In practice
Projects put in a lot of effort mentoring these students, hoping they will stay around after the project or get some coding work done which otherwise might not have happened. This works out to varying degrees - not all students stay, not all code gets merged, and some mentors feel that they put in more effort than it is worth.

Serendipity
While I can not judge the cost-benefit ratio for each project, I'd like to point out that there is a factor you should include in your calculation: serendipity. If you're unfamiliar with the term: it means "happy accident". Simply put, it is the positive outcome of something you were doing for entirely different reasons.

GSOC has benefits beyond 'getting people involved' and 'getting code written'.  Here are a few of these:

• GSOC creates a lot of positive attention around all projects that are involved. The vast majority of this is positive, fun news about features, getting involved in the project and more.
• The students also create a flurry of activity. They ask questions, get answers, write proposals, push people to help them. Activity leads to engagement and for those already involved it is often nice to see interest in the project and stuff happening.
• You also create long-lasting fans with the mentoring of students. They are 18-25, a very formative time in the life of a person. Most will look back with good feelings to their time with your project, even after 'life' has taken them other places. The value of this 'social capital' is hard to judge. But I am sure you understand what it could mean if one of your students makes it to CTO of a big company and they have a chance to do something related to your project!
• Your project learns from the GSOC experience. People learn individually, but projects as a whole learn too. This is not as ephemeral as it might seem: the way your project works is build upon many lessons-learned. GSOC makes your community adapt to new requirements of coordination and organization - learning!
• Sitting down together, thinking about ideas and discussing them is useful. You find out what your fellow team members think about ideas, what you could work on in the future - and perhaps you come up with The Next Big Thing™ ;-)
• Last but not least, there are networking opportunities and collaboration with other organisations. Some of the mentors and students travel to the GSOC meetups around the world, having an opportunity to discuss mentoring and getting new people involved with other teams. This is of course especially true when you collaborate with several communities together, like +openSUSE does this year with +ownCloud, Hedgewars and Oyranos.

I started this blog because I wanted to remind our students that is time to start creating proposals for Google Summer of Code 2013. But I'm hoping the above is also inspiring for mentors - there is still time to get involved!

So what to do?
For students looking for a project, I integrated the openSUSE/Hedgewars/ownCloud/Oyranos ideas I understood (that's a subset...) in the article so readers would get a glimpse of what GSOC for openSUSE has in store. It is cool stuff: integrating maps in apps in ownCloud, fcitx in wayland, comment support in OBS and much more.

Meanwhile, of course, there are GSOC idea pages all over. I checked out the KDE ideas page too - being the largest GSOC project in the last few years, I did expect quite some nice stuff. Oh boy... From web applications and library work to Amarok, Digikam and Plasma, there is a huge number of really cool ideas.

openSUSE and KDE are just two of the many organizations involved in GSOC. If you're a student, think about applying. And if you're a current contributor, think about how you could help your project by helping a student!