Principles

We recently did a post about the Nextcloud Mission and Principles we discussed at the previous Contributor Week. I guess it is mostly the easy-to-agree on stuff, so let me ruin the conversation a bit with the harder stuff. Warning: black and white don't exist beyond this point.

Open Source

In an internal conversation about some community pushback on something we did, I linked to islinuxaboutchoice.com - people often think that 'just' because a product is open source, it can't advertise to them, it has to be chock full of options, it has to be made by volunteers, it can't cost money and so on...

But if you want to build a successful product and change the world, you have to be different. You have to keep an eye on usability. You have to promote what you do - nobody sees the great work that isn't talked about. You have to try and build a business so you can pay people for their work and speed up development. Or at least make sure that people can build businesses around your project to push it forward.

I personally think this is a major difference between KDE and GNOME, with the former being far less friendly to 'business' and thus most entrepreneurial folks and the resources they bring go into GNOME. And I've had beers with people discussing SUSE's business and its relationship with openSUSE - just like Fedora folks must think about how they work with Red Hat, all the time. I think the openSUSE foundation is a good idea (I've pushed for it when I was community manager), but going forward I think the board should have a keen eye on how they can enable and support commercial efforts around openSUSE. In my humble opinion the KDE board has been far to little focused on that (I've ran for the board on this platform) and you also see the LibreOffice's Document Foundation having trouble in this area. To help the projects be successful, the boards on these organizations need to have people on them who understand business and its needs, just like they need to have community members who understand the needs of open source contributors.

But companies bring lots of complications to open source. When they compete (as in the LibreOffice ecosystem), when they advertise, when they push for changes in release cycles... Remember Mark Shuttleworth arguing KDE should adopt a 6-month release cycle? In hindsight, I think we should have!

Principles

So, going back to the list of Nextcloud's Mission and Principles, I say they are the easy stuff, because they are. They show we want to do the right thing, they show what our core motivation was behind starting this company: building a project that helps people regain control over their privacy. But, in day to day, I see myself focus almost exclusively on the needs of business. And you know what, businesses don't need privacy... That isn't why we do this.

Oh, I'm very proud we put in significant effort in home users when we can - our Simple Signup program has cost us a lot of effort and won't ever make us a dime. The Nextcloud Box was, similarly, purely associated with our goals, not a commercial project. Though you can argue both had marketing benefits - in the end, a bigger Nextcloud ecosystem helps us find customers.

I guess that's what keeps me motivated - customers help us improve Nextcloud, more Nextcloud users help us find more customers and so both benefit.

Pragmatism and the real hard questions

Personally, I'd add an item about 'pragmatism' to the list, though you can say it is inferred from our rather large ambitions. We want to make a difference, a real difference. That means you have to keep focused on the goal, put in the work and be pragmatic.

An example is the conversation about github. Would we prefer a more decentralized solution? Absolutely. Are we going to compromise our goals by moving away from the largest open source collaboration network to a platform which will result in less contributions? No.... As long as github isn't making our work actively harder, does not act unethically and its network provides the biggest benefits to our community by helping us reach our goals, we will stay...

More questions and the rabbit hole

Would you buy a list of email addresses to send them information about Nextcloud? No, because it harms those users' privacy and probably isn't even really legal. Would you work with a large network to reach its members, even if you don't like that network and its practices? Yes - that is why we're on Facebook and Twitter, even though we're not fans of either.

Let's make it even harder. How about the choice of who you sell to. Should we not sell to Company X even if that deal would allow us to hire 10 great developers on making Nextcloud better for the whole world and further our goals? Would you work with a company that builds rockets and bombs to earn money for Nextcloud development? We've decided 'nope' a few times already, we don't want that money. But what about their suppliers? And suppliers of suppliers? A company that makes screws might occasionally sell to Boeing which also makes money from army fighters... Hard choices, right?

And do you work with countries that are less than entirely awesome? Some would argue that would include Russia and China, others would say the USA should be on a black list, too... What about Brazil under its current president? The UK? You can't stop anyone from using an open source product anyway, of course... It gets political quick, we've decided to stick to EU export regulations but it's a tough set of questions. Mother Teresa took money from dictators. Should she have? No?

It might seem easy to say, in a very principled way, no to all the above questions, but then your project won't be successful. And your project wants to make the world better, does it not?

Conclusion?

We discuss these things internally and try to be both principled and pragmatic. That is difficult and I would absolutely appreciate thoughts, feedback, maybe links to how other organizations make these choices. Please, post them here, or in the comments section of the original blog. I can totally imagine you'd rather not comment here as this blog is hosted by blogger.com - yes, a Google company. For pragmatic reasons... I haven't had time to set up something else!

There's lots of grey areas in this, it isn't always easy, and sometimes you do something that makes a few people upset. As the Dutch say - **Waar gehakt wordt vallen spaanders**.



PS and if you, despite all the hard questions, still would want to work at a company that tries to make the world better, we're hiring! Personally, I need somebody in marketing to help me organize events like the Nextcloud Conference, design flyers and slide decks for sales and so on... Want to work with me? Shoot me an email!

What's Holding ownCloud Back?

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

Easy ownCloud

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

Limitations

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

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

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

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

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

Solutions

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

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

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

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

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

And now

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

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

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

Where KDE is going...

In my blog about conf.kde.in, I promised I would blogify my talk about KDE's future but failed to publish it until now. I thought the content might be a good fit for on paper. It took a while, but the upcoming Linux Voice should feature an extended version of these blog posts about where KDE is going, with quotes from a variety of KDE folk providing some background.

Meanwhile, on the dot I have published an updated version of the first blog post about the technical side of things: KDE software. It is mostly aimed at people not intimately familiar with KDE but curious about what is coming. Users, for example...

If you find a bug, report it to me or the dot editors! And: spread the article around for users and interested people to read...

Building Converging UIs

I just blogged about my article on linux.com about the just-released KDE Frameworks 5 sneak preview.

Convergence in 2010: Plasma Netbook

Converging Form Factors

On the Frameworks, one can soon expect to see releases of KDE's Plasma Workspaces. A Technology Preview of Plasma 2 has already been released and this ambitious project has not lost any of its goals. Today, I noted that ZDNet's Steven J. Vaughan-Nichols wrote about what he expects from Ubuntu in 2014. There, he quotes Jono Bacon talking about formfactor convergence. And the intarwebs are full of people making jokes that Microsoft is copying Ubuntu with their single UI for multiple devices. But let's not forget where they got their ideas...

What is real ambition?

I would argue that neither Apple, Microsoft, GNOME, nor Ubuntu/Canonical are even half as ambitious as the KDE Community in the area of convergence. They are all merely catching up to the state of KDE technology in 2010. In that year, the KDE community released Plasma Netbook, a plasma-based shell optimized for another form factor: the netbook. With far more advanced convergence than anybody today has yet shown: Plasma Netbook and Plasma Desktop share well over 90% of their code, as opposed to not even sharing toolkit or display shell (Ubuntu) and having a completely separate desktop (Apple). On Plasma, widgets can dynamically adjust to the constraints of their environment, be it on a panel, free-form on the desktop, full-screen, in a window or in a tiled environment. And yes, the different form-factor optimized shells be switched on-the-fly. No separate login or account, no loss of functionality, no separate applications for each shell, nothing like that. It just works. See this blog from 2011 to get an idea how the tablet plans were doing.

Plasma on desktop/netbook/phone in 2011.

I understand what Microsoft is doing - trying to build a single user interface for vastly different devices. And I guess we've all seen how it does not work - Apple is smarter, in that regard. Underlying technology can of course be re-used but you simply can not make a UI which works equally well on a 75 DPI 24" screen with mouse & keyboard, on a 455 dpi touch phone, on a 300 DPI touch tablet and a 64" television with Kinect or something like that...

Instead, the Plasma team has build a technology which separates presentation from logic, allowing you to build UI's which adapt dynamically to the needs of the form factor.

Below is a video of Plasma's awareness of the container size in action, like it has functioned since it was released in 2008.


Now I don't deny that in terms of resources, MS and Apple are so far ahead they can make pigs fly. Our more advanced architecture and ideas can't really compete with what they do and as long as we have 0.5% market share on the desktop, Free Software will probably not get the resources it needs to polish things to the same degree. That's a bit frustrating but it doesn't mean we frequently do things far beyond what the big boys do: anybody who has seen the introduction of the upcoming release of Mac OS X and knew about KDE Connect knows we're way ahead of them when it comes to phone-desktop integration ;-)

Moving Forward

All this technology will be brought to a new level with the release of Plasma 5, where your workspace will be able to smoothly morph into a different form factor without even a hickup. So, when it comes to the convergence of formfactors, KDE is lightyears ahead of what the competition is even aiming for. And outside of that, we're doing awesome stuff, for sure.

Did I say something about the power of innovating in the open? That's what I'm talking about.

Klyde coolness update

I've heard Will Stephenson, Klaas Freitag and Frank Karlitschek talk about a lighter and/or easier KDE based desktop forever. And while I shared the ambition, implementing it is always easier said than done.

So when Will asked me to join his Klyde Hackweek project, I thought - awesomeness, let's try and finally move something forward! And that happened, we had lots of fun and I learned some real packaging tricks. I'll bore you with epic details at a later time ;-)

We realize the idea of Klyde and what we aim to do is a tad vague so Will and I had a long chat yesterday and came up with some more details about our focus.

1. Modular for everybody

The first goal is to make everything more modular. The openSUSE KDE team did a huge effor here, simplifying dependencies so you can have a Plasma Desktop without most applets, Activities, Nepomuk or Akonadi. Of course, that means you give up on good and useful functionality but reality is that we don't always need everything. This way the functionality is optional and this will hopefully become the default packaging state for openSUSE. What you don't use will not add menu items, widgets and memory usage to your system.

By default, a 'Klyde' desktop comes with none of the above-mentioned things and only a minimum of applications and applets. But upon installation of Activities the widget will be added to your panel and Akonadi will fire up the first time you start up KMail or Akregator!

2. Low footprint if you want

We know that 'lightweight' is not easy to define and it is hard to do scientific measurements of memory usage and all that.

Currently, the Klyde settings have some obvious things (disabling animations, disabling some services etcetera) and lots of temporary choices (plastique as widget style for example). We WANT to make informed choices here and input from developers on what is faster (even if that means loosing some functionality or eyecandy) is very much welcome. And we realize work will be needed: we would greatly welcome help creating a fast and efficient widget style, for example.

3. Simple by default

systemsettings simplified.

Systemsettings exposes about 80 different modules to the user. Some of these you'll (almost) never use. And many which, from an user point of view, belong in one place (like theming) are split over several categories due to technical implementation details. It is noticeable that this was designed from the technology up, not from the user requirements down. I spend a big part of my hackweek figuring out how these categories are populated and the modules are shown, then creating an alternative tree with only about 35 modules. Will made a patch to allow systemsettings to either show the basic or the full set of KCM's.

This is an example of what we mean by simple, although we're not done yet. Ideally, these and other improvements will go upstream and we intend to put work into that.

Note that this simplification, in no way, can be scientific. Of course 30 KCM modules is more 'simple' than 80 but it is very much a matter of taste to decide which ones need to be there and which ones don't. That's why we want to put effort in having our cake and eating it too: creating a proper theming KCM might allow us to get rid of a whole raft of theming-related KCM's, for example. Yup, we're still KDE people... But in other places, we are willing to make hard choices based on common sense, research and simply our taste. Unless a designer can convince us he/she Is Right™ we reserve the right to make bad decisions.

Feedback?

We're open for feedback and would love to hear input. Please remember that we're trying to get stuff done so if you have input, put in the effort to make it useful. Have mockups, refer to what others do or scientific facts. Remember that we are not trying to create a desktop for experienced computer users and tinkerers: they can easily morph the normal Plasma Desktop into what they want. It's what I do myself, its what the vast majority of people who read this do.

Instead we aim for a wide cross-section of people who don't want to put in the cognitive effort to understand abstract stuff like virtual desktops or activities. If you understand and use these things to be more productive (which I do myself, by the way), you're not our target audience.

If you want to help out, join the #opensuse-kde channel on freenode and check out our trello board.

Enough talk

Enough talk? Wanna try it? Yeah, it ain't perfect yet, but I've created an initial Studio image and published it in the Gallery. It can be installed, if you insist, but this is a beginning of a work in progress: it will eat babies whenever it can.

Click to go to SUSE Studio for the testing appliance.

About packages and a repo, this isn't easy as you would either have to remove packages by hand or start with a very basic system with only X for this to work. We're looking for a solution there ;-)

EDIT: User and root password for the appliance are the SUSE Studio default 'linux'.

Have fun with it ;-)

Klyde in a VM.

On Open Innovation and Open Governance

Heya,

As I wrote in my blog yesterday, on Thursday the 15th I'll be leading a discussion session about open governance in the Open Innovation track at the 'Summit of new thinking' in Berlin.

Edit: The video of my talk is up...

#SON12: Jos Poortvliet - Open Governance done right: creating rules without ruling from newthinking on Vimeo.

Open Innovation

I'm actually looking forward to that: the 'open innovation' thing was what once got me professionally interested in Free Software communities (while studying Organizational Psychology) and I still consider it an exciting topic. I did my thesis on open innovation but 10 years ago there was barely any research done in the area of open source governance and when I asked questions to my professors, blank stares where the result. These days, things are different (see for example this interview): the Academic world has seen what open source organizational methods can do and there is quite a bit to read about it.

Open Governance

The idea behind Open Innovation is to involve the entire organization with innovation and improving things. Both big and small - we're not just talking about creating 'The Next Big Thing' but also improving current products, structures, processes and more. Think about it as bottom-up innovation.

That only works if you have the right governance: the right structure and rules. Innovation is the first thing you stifle if you make mistakes in how you set up an organization. And you can't just create a 'department of innovation', stuff a bunch of folks in a room and tell them to innovate. It just doesn't work that way. Innovation comes from interaction: people talking to people. Sales together with Engineering, that kind of stuff. Creating an organization which is conductive to innovation is not easy.

Open Source communities of course excel at this: their organically grown structures and informal rules let people 'do what they want' and freedom is the foundation of innovative cultures. But these ways of working have their limitations - you can't be informal forever, not if you grow big. At some point, some guidance has to be there to prevent things from clogging up the wheels of innovation. Things like personal conflicts, fights about creative directions, strategic disagreements. And this is, again, where governance comes in. My session is sub-titled "creating rules without ruling", as in my opinion, it is more about writing down existing but implicit rules than creating new ones.

Qt Open Governance

Interesting in this regard is the Open Governance the Qt project is working on: building such structures 'from scratch' is not easy. You have to find out where you agree, yes, but while writing things down, implicit things become explicit and that goes for (potential) conflicts then too. But being able to do this in a fresh community, before ideas get entrenched! Having a chance to set direction in a 'soft' way. Terribly exciting!

Meet me, talk to me!

If you want to share thoughts with me on this topic, meet me at QtDevDays or at the Summit of New Thinking - or other events in the future (how about FOSDEM?).

In a while, Crocodile!

Edit:
A few video's has been created for the conference. Esp the first one is funny ;-)

Check 'em out:
What is Open Innovation? (Chinese Whispers Game)
Open Innovation Track Day 1
Open Innovation Track Day 2
Rule No.1 for innovation: Have fun!

Pre and post conference blues...

Heya all,

Since the Akademy conference in Estonia beginning of August I've been rather quiet as I have been struggling with health issues. After loosing some blood and undergoing a few *scopy's the people with stethoscopes don't seem too worried so neither am I but it has been unpleasant at times. Not too many tests left - an MRI and another 'scopy' in December, I hope they can give me a diagnosis by then.

It has been frustrating to have had to cancel trips to the openSUSE Summit, COSCUP, Brazil and more. And at the openSUSE Conference (my first trip in 3 months) I had to skip the evening fun - instead opting for quiet food-in-the-hotel and early bed. Believe me: not nice.

new team: 'the openSUSE team'

Luckily, I'm getting back on my feet and at a recent visit to Nürnberg I even went out a night with my new team mates. Yup, a new team - if you're following the openSUSE mailing lists, you probably have heard that already. In my two years of 'community manager' of openSUSE, I've worked with people around the company and community - but I was not really part of a formal team. Independence is nice but it also can make you take on a few things too many - I know I did. So, when it was decided to try and re-arrange things with regards to the openSUSE Boosters team, I decided it was a good idea to join the team and help it find directions. Together we can do more, and all that.

It means the scope of the former boosters team (now just 'openSUSE team') has widened: I will of course continue to care about the things I used to care about. Things like the atmosphere in the community, governance, strategy - and of course marketing, the ambassador program and presenting a friendly face to the wider Free Software world. But I'll be doing that together with the rest of the team now, not alone!

Things are quite different now, so let's see how it'll go.

Conference last month

So, the openSUSE conference was my first event since a while. It was quite awesome, with a lot of faces I hadn't seen in a while and a lot of excitement. We organized a bunch of interviews with people, which will be released over the coming months. On the openSUSE days, a few important things were discussed, results of which have been posted to mailing lists. I'm working on a summary of that but it'll take a bit longer. One thing I already managed to change: Richard gave some feedback on the 'we believe' poster and we decided it needed a fourth item. Which I added, see the image on the right.

You can get the source for the poster in our github repo.

Conferences coming

There'll be more events, of course. On short notice, I'll be at the QtDevDays in Berlin - it's practically next door and a great way to meet people. I've heard we can expect 500+ people there from all over the (huge) Qt ecosystem. It'll be interesting to talk to people outside of the usual Linux crowd: Qt has managed to grow well beyond the Linux Desktop into an industry standard for a wide variety of use cases.

Open Innovation and Open Governance

On Thursday the 15th I'll be leading a discussion session about open governance in the Open Innovation track at the 'Summit of new thinking', also in Berlin.

I'll write a tad more about that in a blog tomorrow.

For now, I have a conference to dress up for, so see you later, alligator ;-)

Keynote about Open Science

At Akademy, about an hour ago, the keynote by Will Schroeder from Kittware was finished. It was a very nice talk - and I've collected some notes, see below!

What is this thing called science?

After introducing Kitware and what they do ('all things scientific computing related'), Will starts to talk about science: where does it come from?

You might remember this Descartes dude. He questioned everything - and that is where it started. Nullius in Verba, "take nobody's word for it", that was the thought behind this movement.

And realize that this did not go down easily! People where locked up for this, faced jail time for their convictions. They were the hackers of their time, trying new things, finding new ways. And sharing knowledge.

Because that is what science was (and should be) all about. The way it worked was as follows:
A scientist wrote a paper, a letter. This would go to the Royal Society or another 'science institution'. There the experiments were replicated and verified. Once verified, the letter, paper or book was replicated and distributed through society.

Things changed since then

But commerce took over and now, the process goes from scientist to commercial publisher where volunteers do peer review and then the article gets published in a journal.

This looks like the same process, but it is not. First of all - in reality, replication of experiments does not happen. There is a number of reasons for that, some practical (huge computational requirements, growth time of tissue samples) but often it is also lacking data, details on how the experiment works or closed, unavailable software or procedures.

The thirst for {fame\power|control|money} has tainted science: we've lost the search for truth. It is "publish or persih", career pressure is huge and scientists are afraid to share knowledge because it might loose them a paper or even patents and licensing income.

Meanwhile, according to a case study, licensing revenue on patents is about 2 billion, but if you substract the costs the university breaks even. And the push for patents is corrupting and damaging science and creates resistance to collaboration.

The results

And it shows: Nature published a study showing that more than 90% of papers in science journals describing 'landmark' breakthroughs in preclinical cancer research are NOT reproducible and are thus just plain wrong.

Will gives a computational science/medical imaging example. It is quite complicated - but boils down to the fact that we can't reproduce the result because we lack knowledge of how it was obtained.

So there is a huge pressure on scientists to do bad science and nobody checks up on the results. Meanwhile, journals take easily 2 years and hundreds of euro's to publish their articles and you also have to pay thousands to read the results - which were peer reviewed by volunteers!

Our data is unavailable or put in proprietary formats, publishers control the flow of information and closed and proprietary software is used to do analysis and controls how scientists work.

What we need

What we need is open science: open access to knowledge, open access to data and open access to source.

It is a real tragedy that we have to put the word 'open' in front of science!

But we have to. Science, part of this three hundred years old tradition of hacking and sharing knowledge, has been corrupted and locked up.

The good news is that things are changing. Universities realize that the status quo does not benefit society and change their policies. Harvard now asks professors to publish in open access journals and the UK is going to only fund research which ends up in the open.

Of course, we already knew that: both society and business show a clear trend. Open is better and will take over closed!


note that these are personal notes and not reviewed: no guarantees about the correctness!

keynote by Agustin Benito Bethencourt at Akademy

Agustin wanted to talk about success. Times are a tad uncertain now - in the economy, in software and in the KDE ecosystem. It's good to be aware of how well we've been doing over the last 15 years and how well we are positioned for the next decades!

Success story 1

Active patience

We now have an open development process around Qt. Once upon a time, nobody believed that to be even remotely possible - it was not even free software. But we knew how the Qt people wanted the things we wanted and we had the patience to wait and quietly keep pushing. And now - the unexpected happened. This will have a pervasive effect on our infrastructure. We (and others!) can now more easily take Qt in other directions, do new things!

The lesson is, in the words of a Chinese proverb: Be not afraid of growing slowly, be afraid only of standing still.

Success story 2

Magister

KDE is first class in getting new, young people involved and educating them. Our contributors are from a variety of cultures, students or established developers - we all work and learn together. And being involved in KDE you learn a lot. Once you start working in companies you will notice how much you've learned in KDE. And that should make you confident that those who will take over in the future, also part of this community, will be ready for it.

Success story 3

Efficiency

As a 'loose' bunch of volunteers, we're doing incredible work. Most companies in 'our business' do a far worse job at developing products with often far more resources.

Success story 4

Leadership

We're becoming better and better at becoming business incubators. More and more entrepreneurs step up in KDE and start new, cool, innovative businesses. We're proud to be part of a community where innovations can go somewhere!

Success story 5

Vision

We're capable of developing and executing on a vision. Take KDE 4! We've embarked on that vision seven (!!) years ago and today - while it is not perfect yet - we've gotten very close. Most of the plans we decided on are implemented and have come into reality. All that without investments of millions and millions by large companies. We did the impossible!

There are people out there who have their own ideas and projects and who want to be part of KDE, develop under our umbrella, our vision and who join us. This tells us we're on a path to a bright future: we're not just open to people, but there are projects outside who recognize our clear vision and the fact that we deliver.

Success story 6

Experience Innovating
People see how hard it is to stay in the tech business for a long time. You see that with many companies. Yet, we're 15 years old, yet we are still doing new, innovative things. What we do is completely different from what we did, but we still do it with the same spirit and energy than when we started. And Agustin is confident that in 10 years we'll still be approaching entirely new challenges with that same energy!

KDE's future depends basically on US.

These 6 examples (and we haven't even talked about design, the project and code, design or many other things) tell you something about KDE: we have a bright future!

We've gotten to a point in which most limitations we're facing come from inside, things we need to and can change. Not from outside but under our control! There is little out there that can stop us from being successful for another 15 years!

(Agustin holding a Plasma Active tablet) Innovation does happen right here!

On the value of collaboration

I finished my monthly column for Linux User last night - way late, as usual. It was about a number of projects openSUSE has going on to improve software installation. Porting Ubuntu Software Center to PackageKit, website integration in OBS, the improved online software store and last but not least the release of the snapper website. And I noted that all of these are cross-distribution: we're not just trying to improve openSUSE, we're trying to improve all Free Software. And it's not just us - I feel there is more and more collaboration in the Linux space (not that there aren't exceptions of course).

As conclusion, I wrote that

I personally believe that any project which fails to have this ambition will fail to really make a difference in the long run. Free Software is not just about 'abiding by the rules of the GPL' - it is about working with others.

What happens if you don't collaborate?

Let's talk about that. Who remembers Xandros? Linspire? They once were quite popular Linux distributions. So, they contributed a lot back to Free Software, right? Not really... They didn't work up-stream, instead, they built unique features like the Xandros Filemanager and Linspire's software management tools. Sounds familiar? right...

So, I believe that if you try to isolate yourself from the rest of the Free Software world, you're not only doing yourself a disservice, but all of Free Software. You can claim you contribute - lots and lots. Bringing in new users, making things simpler for end users (that's what Linspire and Xandros said, yes). But if you don't do it in a collaborative fashion, you have to carry more and more load yourself. Red Hat and Novell learned that the hard way - and now both companies have a strong policy: nothing goes in unless it is upstream. Yes, that benefits Free Software, of course. It's how we work. Even Google gets that and puts in significant resources to get their changes in the Linux kernel.

If you don't do that - you're work is irrelevant for the future of Free Software. Distribution-specific package managers are a great example: any distro hopper who has been around for a while can't count the different tools he/she has been using on two hands anymore. I know I can't. Most of these were cool, really. And most are dead code these days. Let me repeat:

non-collaborative efforts fail to make a difference for Software Freedom in the long run

But... but... but...

You'll say: but the code is free! Yes, it is. Which is about as valuable as... Let's see - how many distribution-specific package managers have been ported to others? Exactly. Very few. And most of those have very quiet lives. You say - but Linspire did lots of marketing. We brought new users in contact with Linux. That's cool, don't get me wrong. But at the same time they were channeling effort to a small world-on-its-own instead of directing these people towards understanding the wider ecosystem. It's not the number of users that counts, but what you do with it.

Collaboration is not easy - I really applaud the efforts of dantti who's putting in lots of hard work to improve the situation in the software installation area. I really look forward to the day openSUSE uses Apper as the one and only package manager on KDE desktops (we're working on making Ubuntu Software Center PackageKit based for GNOME desktops). And I call on other Linux Distributions: put your efforts in a place where it matters. Collaborate. Especially those calling themselves proudly KDE distributions - put your efforts where your mouth is... KDE's a very open, collaborative project and this is a real step forward for Free Software!

Of course, the same goes for GNOME projects. Ubuntu Software Center is a nice piece of software and if we make it work on top of PackageKit it's not hard to adopt it. Port it to GTK3, integrate it in GNOME shell, make it better for all of us. Maybe, some day, even Canonical will see the light and collaborate...



Edit: Before going live, I added this as 2 reviewers of this blog pointed this out:

• Canonical fans might think that as usual this is all about them.
  It's not, actually. Surely Canonical is a great example of the next Lindows - no company stays around forever. Some day, SUSE won't be around either - nor will Red Hat. And as I said I believe that without collaboration with others there will be no 'legacy' - but the desperate attempts by Mark to justify the lack of collaboration wasn't what prompted this blog. It was actually the positive side of things - the work openSUSE does, of course, but also Fedora (Kevin Kofler worked on a cross-distro GSOC project last year) and the awesome debian-screenshots people. And many people around GNOME and KDE - those smart enough to realize that collaboration makes Free Software stronger and building your own garden makes it weaker.
• But who cares about the benefit to Free Software?
  I do. But if you don't, I don't judge. Most people don't care much about a great deal of things others do care about. From puppies to privacy invasions to dictatorships to hungry children. You can't care about everything and if a Linux distro does what you need from it, despite not working with others and you couldn't care less, why do you even bother reading my blog?

CLS, DS, COSCUP... Plasma Active, ARM, ...

It's been quite a while since I wrote a decent blog and it might be a while longer until I really get to it. I do have a lot to write about, however. First about the Community Leadership Summit - the notes of which I'd like to turn into a few blogs. Second, the Desktop Summit, which was awesome. And third my trip to Taiwan. Finally the upcoming openSUSE conference which is going to be awesome. But let me get the most important stuff out of the way first.

Desktop Summit Awesomeness

At the Desktop Summit (which imho was a great success) I organized 3 food cooking parties where we made some Asian-inspired curries. I've put the recipes on-line for those who asked for it. Find them on the Desktop Summit Food page.

At those cooking evenings we had between 25 and 30 people join us each night. It was big fun, we had good food (and beer and more) and I really intend to do it again next time. As a matter of fact, I hope to do the cooking again at the openSUSE Conference. And remember - if you don't use openSUSE that doesn't mean you can't come and enjoy the company, food and discussions about all kinds of things. See for yourself in the detailed program. You can also learn how IO travels in the kernel, how to use the mtux console multiplexer, the sessions about GIT, cross-cultural communication, GCC and Kernel stuff and more. And that's just stuff from day one, we have about 100 sessions in 4 days.

Talking about cool stuff, on Tuesday we'll have an 8-bit music workshop... Seriously, I look forward to that. If you want to join, hurry up, the conf takes place September 11-14!

!Fail

Taipei and Plasma Active

Last week I made a trip to Taiwan to meet the openSUSE community there. There's quite a bunch and they did awesome at the booth at COSCUP. Really cool. We had lots of interesting stuff there, flyers, geeko's, stickers, USB sticks and Aaron left his Plasma Active tablet (runs openSUSE, of course) at the booth a few times. That thing drew quite a crowd - and rightly so. I hadn't seen that much of it but Plasma Active is really something very interesting. It's a unique touch tablet UI, yet easy to use and intuitive. Build in just a few months it's amazing to see how well it works already. The team aims to stabilize it in the next few months and I'm absolutely certain it will result in a pretty darn impressive product.

Aaron spoke quite a bit about how well the Open Build Service works for them during development. The team works closely with an interaction designer and obviously she's not such a hugely technical person. With a traditional development process someone would have to do packages for her - or she'd have to learn how to check out a repository and then compile and install stuff herself. Thanks to OBS, packages are build continuously and very easy - a dev checks some code in and the next day the designer can give feedback! Continuous build services are not unique of course but they usually don't come easily, don't produce packages, etc. build.opensuse.org has an easy web interface, can build for all major Linux distro's and architectures (yes, including ARM) and is of course entirely free.run it in-house,

I'm quite proud that openSUSE proves to be so successful for the Plasma Active team. They also build packages for MeeGo, as they want to support ARM systems. I know several openSUSE contributors want to have ARM in openSUSE, well, Plasma Active is at the openSUSE conference so we can meet and talk about it there...

Anyhow. So Taiwan was fun. You can find some pics of COSCUP on flickr and I have an image of two of my hosts as well as fellow visitor Aaron below :D

You'll probably find all three of them at the openSUSE conference too, btw.

criticism towards GNOME Shell

Reading all the controversy around the decision by the GNOME Shell designers to remove the minimize and maximize buttons from GNOME shell reminds me quite a bit of the discussions around Plasma. Especially for stuff like the brilliant yet controversial Folderview widget.

criticism

It also makes me wonder if those complaining have ever tried GNOME Shell... As is adequately explained in this rationale, minimizing simply has no place in the concepts behind GNOME Shell. Period. And if you've tried GNOME Shell you would realize that.

GNOME Shell in openSUSE 11.4

Yes, Shell takes getting used to, it does enforce certain habits. If you want to customize your environment for maximum 'getting-work-done' then maybe GNOME Shell is (currently) not for you. But that's the crowd KDE has always appeased to anyway. There is after all a trade-off between efficiency and ease of use (or rather, discoverability) - it is why most seasoned sysadmins use a command line.

Newbies!

But the power of GNOME Shell lies somewhere else. Put a newbie in front of it. Observe - in 5 minutes they've figured out how to use it, really. It is very simple and intuitive. I find that very impressive. Especially on a touch screen, it all makes a lot of sense. And it also works on very small screens. And yes, you'll see, the minimize button DOES NOT make sense in GNOME Shell. Really.

If you want to criticize GNOME Shell, talk about technology. I would've advocated to not build a new tech platform but build Shell on something like Plasma which is designed to make interfaces like GNOME Shell, or do like Ubuntu did with Unity 2D). But I kind'a get why they didn't, it's software 'from the other camp'. A more harmful thing is that they didn't get involved with the fd.o systray/notification rework done by KDE and Ubuntu, I see it as a big miss for GNOME Shell, and I'll consider it narrow-minded until I see or hear a good rationale somewhere ;-)

Plasma 4.6 and KDE Apps in openSUSE 11.4

But don't balk at the design until you've tried it with your grandmother... And in the end, Shell is innovative and new and will need maturing. I always have a soft spot for innovative and new things, it's why I like Plasma despite the issues it still has. So I do look forward to the final release of GNOME 3 and I'm happy that we (openSUSE/Novell) decided to press GNOME 3/Shell LiveDVDs as soon as the release of GNOME 3 is out. Yes, we'll also make KDE ones, 4.6 on openSUSE 11.4 really rocks and deserves it ;-)

KDE strategy for openSUSE

As I mentioned in two earlier blogs now, within openSUSE a strategic discussion is going on - what direction should we, as a distribution community, take?

I would like to address a few things in this post. First of all, why a strategy, and what will it and won't it do? Second, there is one strategy I'd like to mention specifically, as I think it's disrupting but as a community proposal it deserves to be discussed as any other strategy. That's about the KDE strategy for openSUSE.

Strategy

But first about the idea of a strategy in the first place. The strategy portal page talks about it plenty and I won't repeat that. I only want to stress what a strategy does and doesn't do.

It does:

• help make project wide decisions; for example say we choose the home for developers proposal and the liveCD is full. Do we remove the second media player or the second debug tool? The first it is...


• help focus marketing; say the marketing/promo team wants to set up a campaign targeting a group of ppl, who should they choose? A clear focus helps a lot.


• help attract contributors; having a clear story and purpose helps attract contributors. It will also attract a specific kind of contributors, to be precise the ones to whom the strategy appeals and who are thus likely to implement it.


• help in making a choice; if you're a contributor or user you have certain needs. Looking at the strategy and marketing can help you make a decision for one or another distribution!

Note that all these serve to make the impact of the strategy bigger over time - people who like it will start using it, voice their opinion, get involved, steer...

It does not:

• mean we become less open; so if you want to focus on creating a pro-audio spin while the community has chosen for the focus on developers - go ahead. Nothing will change in that department: who codes, decides, and we're an open community.


• mean we will actively remove things which don't fit the strategy; so if we focus on being being a mobile and cloud distribution, we won't remove OpenOffice for Google docs! We might put a Google Docs button in the menu, next to OO.o, or we might put resources in google docs import/export instead of MS Office 12 support.

So a strategy gives focus and direction, but does not limit much - except when it comes to either-or questions where it gives direction. A strategy is also broad - it has influence on pretty much everything you do. Example: server technology. The cloud proposal has influence on openSUSE as a server - we would integrate and ship things like OwnCloud, Etherpad and similar server technologies in an early stage. As a base for deriviatives we would make sure setting up a server can be done easily from the SUSE Studio GUI. And when we aim for developers, the build service should be integrated so developers can write their application and build it for over 10 distributions with one click.
And third, besides giving focus and being broadly applicable, a strategy also unites. It gives everyone in the community a common goal, lets us focus on our strengths, and binds us.

the KDE proposal

Looking at those three goals of a strategy you might understand a bit better why the number 1 KDE strategy ain't the best of the proposals. While you all know me as a KDE guy, I can't really support this idea. Talking to the strategy team and the dude who submitted it initially (Marcus), it has been improved a bit. It used to just talk about KDE - as in, let's be Ubuntu for KDE. That is focusing on a solution, not stating the goal or the problem you try to solve. Now it proposes to have a strong end-user focus, making it a bit more inclusive. You can then choose the right technology for the right job.

broad

Still, while the strategy focuses on a traditional strength of openSUSE (a great integration of KDE apps and a good Plasma Desktop setup), it does not bind but it segregates.that is another traditional strength of openSUSE: being a broad, all encompassing community. This strategy is not broad at all (it is still only about one desktop technology) and does thus not give direction for a large part of the openSUSE community. Moreover, it's too specific and technical to attract most 'common' users. They aren't interested in technology but in the result.

bridges

I think it might be good for KDE and in the long run might work for openSUSE. Even though focusing on technology instead of the goal (end users) Not so sure about Free Software in general however. We, as in the Free Software desktop community, were just starting to build real bridges between each other - next year will have a Desktop Summit again!

Perhaps more important, this proposal would chase away an important part of our community - the many non-KDE users and contributors. And the costs could be serious and in many area's. KDE and Gnome technologies can help each other. A good example of that, something I've been lately involved in (yet I needed Bryan to remind me of it) would be a11y or accessibility. This is something which has been moving within the KDE community lately, in part due to some inquiries a government organisation did at last Linuxtag. However, there currently are very few good tools like screen readers written on KDE technology, to eg the Orca screenreader has to be used. Which is fine - and something openSUSE has an edge in as we ship both good KDE and Gnome libs and apps!

What it should be

I think it would be good to have a proposal focusing on end user products, on something aunt Tilly can work with. openSUSE could be a distribution aiming for polish, the final touch. Working on creating a great end user product. And both the Gnome and KDE people would be able to work with it, as would the Apache team, the Kernel team and all others in the community!

my offer

I'd be willing to write such a proposal (yes, short notice, I know) if ppl think we should have it. I'm NOT saying here that that's the direction we, as in openSUSE, should choose - personally I like the poweruser proposal as well as the developer proposal. Oh and the cloudy one as well... Besides, I've been involved only so short, my vote doesn't count as I'm not even an openSUSE Member right now. So the openSUSE community should vote - not me. I'm just here to help!

Being Free - why it matters

Hi all,

Ok, so the blogs about being free are done (last one) - I just want to add a few thoughts here before I throw myself on the blog about my earlier LinuxTag Flames. FYI this will probably be more controversial than that one, so brace yourself (or don't read if you don't like honest yet strong opinions).

This is related to some discussions on the web about the FSF, the FSFE, and pragmatism vs idealism. And prompted by Ben Martin's blog about Meritocracy.

Let me tell you my point up front: those who see a difference between pragmatism and idealism in FOSS are wrong.

Read on to figure out why I say that...

Basic assumption
We want as much Free Software as possible, right? Let's first look at why we want that:

• Because it is better for Freedom. "In a world where speech depends on software, Free Speech depends on Free Software." (Donald B. Marti Jr). Need I say more?


• It helps companies to be independent of a few large businesses, it is better for the economy. FOSS promotes a free market where everyone can choose from a series of vendors.


• It's good for second- and third world countries because they don't have to waste dollars on big US or European companies and they can learn from the code.

And I'm sure there are more reasons. So, our goal should be simple: spread as much Free Software as possible, and educate people about it. Firefox does great in this regard (at least as much as can be expected) by showing the why on their site and in the browser when you start it for the first time. Oh, and they do it this way: FIRST get them the software (free as in free beer), then try to educate them. Firefox has been very instrumental in me explaining what I do for KDE to completely IT ignorant people. I say, I am part of KDE. It's an international blablabla doing FOSS. FOSS? Yes, ever heard of open source, linux? Nope. Firefox? Yes, I know $friend using it. Ok, so that's developed by volunteers in their free time. They do that because they believe it helps make this world better. blablabla. Thank you Firefox!

Idealism vs Pragmatism

So where is this idealism vs pragmatism? Well, some people apparently dislike Ubuntu because it makes it easy to get non-free codecs. Or dislike openSUSE because it ships binary firmware. Or firefox because they make money thanks to Google. Well, screw that. Sure we must try to get such things to be opened up, but what end user is interested in those niche 'pure FOSS' distro's which barely run anywhere, can't play mp3's or can't visit Facebook, gmail and other popular sites?

Others are against making money with FOSS. Doesn't get any sillier. I'd rather have Novell make a deal with MS, letting our 'friends' from Redmond distribute SUSE licenses, than not have these customers at all. Sure such a deal has disadvantages and I don't know enough about the details to properly argue about it, but the basic principle I have no problem with. And there are plenty more examples more or less like this. Google's deal with Firefox. Ubuntu One. Darn, if BP sponsored me to do marketing for a year, fine, as long as they don't expect me to say to the world I think they're doing great in the Mexican Gulf ;-)

Idealism is going for the BIG WIN. Pragmatism is how you do it. They're two sides of the same coin. That's what I think.

It's about the world, stupid

I want *the world* to use Free Software, not 1% geeks. Commercial parties can play a huge role here, and I'm happy to let them experiment, stumble and fall, get back up and *spread the darn software* in the process. Because I believe in the end, it will work out. Take dual licensing. Is it evil? Hell no, in the end it turns out the 'free' version becomes so much better the model doesn't even work anymore... See MySQL, for example. In the end, money goes into improving Free Software, and the FOSS model ensures domination ;-)

Let me put one thing straight: I'm perfectly fine with those who hack on FOSS because IT IS FUN and don't care much about anything else. Power to you. I'm argueing with those who say they want everyone to be free and use FOSS but at the same time restrict people in what they can do!

Conclusion

So pragmatism vs idealism is wrong. You need pragmatism if you want your ideal world, and by only idealism you get - fairly litte. And the FSF has done plenty of pragmatic things, which is why they made a huge difference. The reason I mentioned them is that lately, some actions seem a bit too extreme to me... But there are ppl out there in 'our world' who are FAR more extreme, and hindering FOSS adoption that way. Either by opposing things, stopping others who're doing great, or just being negative and thus giving a bad impression to the outside world.

I admit, I might have went a bit over the top in the text above and there are probably plenty arguments to explain why some examples were wrong. And I admit, there are things you shouldn't be doing, there are boundaries. But in the end, it boils down to: do you want to spread Free Software everywhere, or are you just focusing on your own narrow group of fellow hackers?

I go for world domination. I want the vast majority of people on this planet to use Free Software, knowingly or not. What about you?

On Being Free pt 3

This is the second time I wrote this blog (wanted to publish before LinuxTag already) so I'll really try to keep it short. It is based on my talk on this subject at LinuxTag, which in turn was based on the earlier blogs about Being Free and discussions I had the night before the talk.

I'd like to refer to my earlier post where you can find links to earlier blogs.

Topics I'll go through:

• Good and Bad sides of Being Free


• 7 reasons why we're Free and What We Can Do


• The Challenge

The Good and the Bad

So the way our community works as I described in my previous blogs has good and bad sides. Good is that we're the most innovative and fastest growing FOSS desktop community, having a lot of fun developing truly Free Software. But there is Bad. I've touched on that in my flameworthy LinuxTag blog (and I will come back to that topic in a future blog). The way we develop software is often bad news for the end user experience, and makes it hard to work with companies. We don't have a strong single point of contact for them.

So in pretty bullets:
Good

• Lots of fun


• Much innovation


• New volunteers & large growth


• freedom

The bad

• Too little focus on end user experience


• Difficult cooperation with companies

7 Reasons & Actions

The question: can we improve our end user experience and work more closely with companies, while not losing the advantages of how we currently work? Let's move to the 7 reasons Why we're Free..

1. Strong focus on technology and cool things
We're a technically oriented community – in a discussion everybody is equal (assuming you're also willing to do the work). This is deeply embedded in how we in KDE think and work. This is something for our communication. Talk about this with each other. Every time you blog about a very cool thing you wrote or difficult problem you solved in an original way, you share our culture. So, blog! Even if it’s short!

2. Flat organization, little hierarchy
We don't really do 'bosses' and 'code monkeys' in KDE, and we shouldn't. New developers are coming in, paid to support come projects. They’re no different from us, so don’t treat them different!

3. Having a diverse ecosystem
Getting more companies with different business models involved in our community would be good. The increased interest in Qt thanks to Meego can help here, but we, as in the community and esp marketing people, should be working on this. And we are ;-)

We're pretty successful in reaching out to local contributors. I think we owe a great debt to some of our contributors who are very active in their local communities, getting people closer to the international community. But we need more reaching out - seen my series on who is KDE? Join that theme and bring outside contributions to the light!

This is something I'm working on behind the scenes, expect an announcement during Akademy.

4. The role of KDE e.V. is strictly supportive
The e.V. is our legal 'mother', supporting and protecting us in doing what we do. Officially, mommy has no say in what we do - in reality, most core contributors are a member of KDE e.V. and of course heavily influence development and the board sometimes does represent us to companies. However, that doesn't happen very often - the central role the Gnome Foundation plays is certainly not copied by KDE e.V. which has lost us (according to some ppl I spoke with) some potential important commercial contributions.

If a company asks the board: "We want to do this, will you accept the code which follows out of it?", and the board has to say "I dunno, ask $RandomBunchOfVolunteers", the company might go like "Yeah, right..." and move on.

So, should the board be more active in working with companies, approaching them, even? Personally, I think yes. But we should be very conscious of the risk of influence by the companies they work with. We're spending more and more money, the majority of which comes from big companies.

The Join the Game (supporting membership program helps make us less dependent on the big sponsors. A reason to join! Another thing is that we simply need to be aware of this issue and talk about it. Maybe we need to come up with some rules and agreements in this area.

5. Regular developer meetings - keep talking
The regular meetings our developers attend keep the community bonded together and increases cooperation with corporate contributors. So let's keep on doing this, the way we're doing it...

6. Meetings are funded by KDE e.V.
See 4 and 5. While I voiced some concerns, generally this is going great.

7. Having had to deal with Qt licensing - history helps
This reason for our 'being free' is very much a historical one, but one we can keep alive by talking about it and thus keeping it in our collective memory.

Conclusion

So in short, we should try and keep us free and independent by doing the following:

• Be Nice


• Reach out


• Share and talk

Moreover, we should think about how we've organized some things. Maybe we can improve the way e.V. works? We are already working on getting community support through the Supporting Membership program; we might want to do more to diversify where our money comes from and give the e.V. more power in talking to companies.

Influence of Money

Part of my blogs about Being Free is talking about the influence of money on (volunteer) contributors.

This is something discussed by a lot of people, so I won't add to this discussion, but it's interesting for sure so I include a few links for those who want to read up on it. For me, it started with this blog about money and motivation by Joe "Zonker" Brockmeier and I initially followed a few links in there. A very early blog about the subject comes from the Gnome community (by Luis Villa) where this issue has been playing for some time. Stormy has also written a few excellent blogs about the subject. Stormy's opinions are worth following in general, and her experience in this area make for some insightful articles.

Let my give a quick summary here:
You can put money into development in 4 ways:

• Bounties (bad, often hurts motivation of others)


• Job (seems to work pretty well)


• Grants (works very well)


• Giving Shiny things (works very well)

Read on in this overview by Bruce Byfield from 2007, he painted a clear picture. For the latest insights, I'd say talk to Stormy...

Flameworthy LinuxTag Notes

As I kind of promised in my previous blog - here some notes from LinuxTag, worked out in an opinion :D. Now this blog is different from my usual ones. While I do write about strategical stuff, I try to stay away from controversial things. Not this time, sorry.

KDE in the early days
At LT I spoke with quite a few interesting people, including Georg Greve (the dot will feature an interview with him soon) and Matthias Ettrich (who started this whole KDE thing). The latter had a fairly interesting opinion about his 'kid'. After we started talking about stuff not for this blog (mostly politics and economics) we came on the topic of why he started the KDE project.

Basically, it was to give the common user access to the freedom and power of a better platform (Unix/linux). When Gnome started he was fine with that as some in the KDE community moved over there and added a whole bunch of features he didn't want in KDE anyway. But at some point, Gnome and KDE started a feature race - which was lost by Gnome, so they re-focussed themselves on user experience with help from Sun. Basically, Gnome 2.0 was what Matthias had envisioned for KDE in terms of user experience. He decided things didn't go his way, and instead of fighting or following the new direction he stepped out and started working on Qt.

KDE now
Since then, a lot has changed. That doesn't include the difference in focus between Gnome and KDE - Matthias complained Gnome builds a great user experience on inferior technology, KDE creates super technology while not doing enough on usability. He's not wrong.

So KDE has created a very open culture which results in innovation, experimentation and new technology. The user experience, while more of a focus than in the KDE 3.x times, imho still ain't what it needs to be, might never be the way we currently work. At least, the finishing touch is boring and hard to do in such an open meritocracy.

How to create usable software
You'd need a strongly design-driven development for a finished, consistent experience, were developers follow a common vision laid out by a few brilliant designers. And follow through on the boring stuff. This simply doesn't fit how we work - developers decide on what happens to their applications and what they spend their free time on. So different applications have different ways of solving certain issues (like with the + hover button on folders). This leads to innovation, and in time to better solutions - but while these are fleshed out (and there is always SOMETHING going on) it makes the whole set of apps less consistent, less stable, less usable.

Users
Another issue is the large influence users have on how we work. Yes, that's right, I'm blaming active users here for unusable software. Many of our vocal users are powerusers and demand features easily accessible which only 1% of the world needs. And we cater to them, which often leads to a more bloathed piece of software. Especially removing functionality often leads to a big flamewar. Gnome simply ignores those who don't agree with the vision they have, and the end result is at least more consistent.

The last mile
Many in our community hoped the distributions or other commercial parties would be able to pick up where we left, and finish that last mile. They didn't - well, they tried, but every distribution which successfully did so either didn't contribute upstream (xandros) or went belly-up, was bought or had to change focus (mandrake/mandriva, suse). Ubuntu does the last mile for Gnome but Kubuntu lacks resources to do it for us.

What do we do?
Now we could start some top-down effort and force these things. Kill innovation, chase away a large proportion of our brilliant developers, having less fun. Please let's not. KDE, as it is, is great. We have a lot of fun, we innovate, and most of our current users love our products. So I am not advocating any change in how we work here. But we need to create a more usable and stable product if we want to grow beyond 1% of the market. So I think change needs to come from the outside. From a new start. How? I do have ideas, but I'll first put on my flamesuit and enjoy the heat...

What do you think?

More on Being Free

About 6 weeks ago I wrote a blog about the state of decision making in the KDE community. I stated that generally speaking we are not heavily influenced by any single entity, something many of us cherish. Because of rising corporate interest in open source over the next years this situation might or might not change - it depends entirely on how we approach the challenges before us.

I realize the previous post did NOT have enough pretty pictures and easy bullet points - I will try to do better this time.

Independence

Let me start by trying to expand a bit on the decision making itself. What does it mean to be independent? Not that commercial parties have no say or influence at all - after all, they contribute in various ways. A problem emerges when for example volunteers feel they're being left out due to the large contributions of full-time corporate workers. This was once described by Till Adam (from KDAB) as the freight train effect. This is problematic for both the volunteers (who might walk away) and the company. Companies often work project-based and need the community to solidify and maintain their contributions.

So the question I see when it comes to independence is NOT: "How do we prevent companies from having any influence at all". The question is: "How do we preserve a balance between company and volunteer input to preserve the long-term health of the community".

Choices

Last blog I concluded we're facing a choice between:

• not caring about our independence
• restricting influence of other parties by not working with them, or only to a very limited extend
• figuring out why we're still our own masters and making good use of that knowledge

The first. Yes, I actually added this one, as there is always the option to do nothing. What will happen if we just go on like we're doing right now? Considering the increasing interest of commercial parties in KDE technology, I guess we'd get more corporate contributors. Larger ones, too, which hire many people in the community to work on certain things. Our technology will spread more and more, and will appear on cool devices. Some companies might try and get their stuff upstream, others might not. But. Corporate influence can be at odds with community ideas (money can do that) which may very well lead to loss of passion for an development area or product some company took over. Things might go downhill from there. At some point, we *might* find us in a situation where our general direction is decided upon by an 'advising' or 'consulting' Board with companies like Nokia, Intel, Novell and other major corporations. We will probably be spending a lot of money on a CEO or a similar function, and choices are made top-down. Some developers will have no problem with this and continue hacking on cool things - it's all (L)GPL, after all. Others might dislike what has happened and will leave.

The second option will keep things in our community more as they are now (though we might even want to chase away some companies working with us as they're very influencial in some areas already). We will probably stay on the fringes, with a small marketshare - but we'll have fun. We can continue to invent and work on innovative technology but I reckon without help of big companies and working with them finances will get a bit tighter than they currently are (less coding sprints?) and we will fall behind in some 'corporate feature' areas volunteers don't like to work on.

And the third option - if we decide to go in that direction, we'd need to be consious of our values and freedom and protect them. We will need to know how it came to be that the KDE community, while one of the largest Free Software communities in the world, still makes decisions by itself and is not dominated by (and depending on!) a single entity or just a few. This will help us expand on our ecosystem of different organisations and volunteers working together. Currently, we get input from a variety of sources, be it independent volunteers, universities, companies or NGO's. Diversity is the keyword here - and we will get more of that. I will expand on this third option a bit further.

What's keeping us Free

So what contributes to an diverse and open development process? Below a list of things which I think have kept us 'sane'.

1. Strong focus on technology and cool things.

Most decisions are made on technical grounds or because users are asking for certain features. In companies, decisions on what is needed in the code are often made by non-developers - managers, committees, marketing people. I'm proud to say I don't have any say in development at all ;-) Generally speaking, companies working with us have had to adopt to this way of thinking, similar to how decision making works in the linux kernel development community: technical merits and arguments, not 'my manager said so'.

2. Flat organization, little hierarchy.

We don't have much if any hierarchy and the different teams are mostly independend. This ensures that no one individual, foundation, or corporation can dictate the future direction of KDE development as a whole. As a result the project can grow more organically, and innovate more easily as well.

3. having a diverse ecosystem.

Having 2 or 3 large companies hiring most developers contains a risk for the independent decision making process by the community. If a much larger variety of organisations (both for- and non-profit entities) contribute in a variety of ways, the opportunity for each to push a certain agenda is much smaller.

4. The role of KDE e.V. is strictly supportive.

Companies have no business controlling KDE e.V. - it wouldn't help them as e.V. is not involved with development decisions, only supports us all in doing whatever we want. If we all wanted to move into the beautiful world of bowling, e.V. would probably continue to support us. We might have to vote for a new president, however.

5. Regular developer meetings.

Our regular meetings don't just help development, they also create stronger bonds between developers. Not only among the volunteers but also with non-volunteer developers. This mitigates the effect of 'the freight train': corporate developers are often sitting in one room and thus have a tendency to start discussing things there and make decisions, instead of doing so with the wider community over the web.

6. Meetings are funded by KDE e.V.

Funding by KDE e.V. instead of specific sponsors per meeting allows more independence of corporate sponsors when it comes to goal setting and justifying the results.

7. Having had to deal with Qt licensing.

The Qt licensing issues early on in the KDE history have made the community consious of corporate influence and Freedom in general. We've set up a Free Qt Foundation dealing with this and receive and discuss regular reports about the status. And of course there's our legal dude in the e.V. (ade), who is rumored to sneek into your room at night and steal your underwear if you allow wrongly licensed code into your app.

Conclusion

I think the community, that is all of you reading this - developer or not, should stop for a second and think about what we want. Personally, I would love to bring our 'Be Free' to every device out there - but I would prefer to do it in a way where we don't loose ourselves. This community is big fun. It is open, it is free, everyone can be a part of it and make a difference. Decisions are made by us, talking and doing. And for that, we might have to put some safeguards in place.

I would love comments on the above, input on other factors I missed and practical tips. Next time I will try, with help and inut from others, to make a list of what we can/should do to remain Free.

The treat

Now a picture as reward for reading through (and thinking about!) all this stuff. This kitty stood behind our back door in our new house meeowing until we let it in. After checking out the room it decided it wanted to sit on my lap (while I was working, grrrr) and I can't say no to cuties so I let it. While finishing this blog it's purring beside me. Aaaw... Any suggestions for a proper name?

On Being Free

As I promised on an obscure mailinglist where the evil plans for KDE World Domination are being developed (and consequently rejected), I'd like to solicit some opinions in this blog about Freedom.

I'm not talking about the free-as-in-beer nor the free-as-in-speech, but the relative independence the KDE community enjoys from the influence of one or a few large corporations. Most of you probably realize that it's a rare property for a community of our size - pretty much all other communities with over a 100 developers (KDE has about 2400 active developers!) are basically run by anything from one up to 3-4 large companies with little or no volunteer input. At a recent meeting Frank, Jeff and myself had with a major manufacturer of mobile chipsets it became abundantly clear that the independence the KDE community enjoys is seen as a big plus by companies who might want to work with us.

Of course, talking with volunteers you are not seldomly reminded how they prefer their freedom. While support from a big company is nice, for many the decision making power has to be with the community, even for those employed by companies. Some say it's because it results in better decisions, others argue it is simply more satisfying to be in control. Whatever the reasons, it matters to us.

Now the KDE community certainly DOES work with big companies, and not just a few. I am compiling a list of companies active in our ecosystem, and it is impressive. Of course some are more involved than others. Some work closely with a sub community, providing incentives for specific features, like XXXX does within the Amarok community. Others have so many developers working on a specific piece of technology they almost run the whole thing, like is the case with KDAB and KDE PIM. Of course, especially in the latter case, the question might come up: to what extend is this community still independent? The answer might be a difficult one, however just asking around gives you a decent idea. The companies around KDE PIM (yes, not just one) put serious thought and effort in keeping the community in control, working with and not behind or over them, supporting and attending meetings and sponsoring several developers.

So despite the corporate input we receive, we still are largely independent and in control, and we'd like to keep it that way. Basically, that gives us two ways forward:
- don't work with commercial parties anymore than we already do, and maybe even tone it down here and there. Effecively keeping our community as it is - volunteer based. Of course organical growth is possible, esp considering that we grow by about 300 (mostly volunteer) developers per year...
- figure out what exactly it is which keeps us independent and keep an eye on those factors while proceeding to work with (more) commercial parties.

In my opinion, the community needs to think and decide how comfortable and happy they are with working with (more) companies in the first place. It might surprise you but there are people with vastly different ideas about this than you might have. We need to get those opinions on the table, and decide, as a community (or as sub communities!) where to go from here.

To help with that, I'd like to make the second option a real posibility: proceeding with increasing corporate collaboration to grow and improve our products while staying independent in terms of decision making. For that we need to figure out 'what keeps us sane', about which I'll be writing my next blog. For now, any input, ideas and discussion are welcome!