Luminosity of Free Software, Episode 9

Today I will be recording the 9th episode of "Luminosity" and it will be a short episode, in part because of time constraints I'm facing today but also because I'd like to experiment with the setup of the show to see if it can fit into a 30 minute form and how the viewing audience finds that.

So .. there will be only one topic this week plus the usual Q&A session:

• Mer: A (not so) new (mobile Linux) hope. The project and the community, a history and an update. We will look at what the Mer project provides and who uses it, visit the community structure and introduce the brand new build service that rolled out to replace the MeeGo build service that is being closed down.
• Q&A: Ask me anything, and I might answer it .. history shows the likelihood of that is actually pretty high.

See you there on Google+ Hangouts at 20:00 UTC. Chat and questions can be found on irc.freenode.net in #luminosity.

Read More

freedom abhors singularity

Today on the interwebs I read an interview with a certain Free software project leader who stated that they were making:

The world's premier and, in fact, only truly free software operating system.

Ignoring that it doesn't actually hold up to scrutiny (there have been many "truly free software operating systems"), this brought to mind a spectacular feature of freedom: it abhors singularity. Indeed, monopoly positions are exceedingly rare in free systems.

Usually the only way to ensure a monopoly exists in a free society is to mandate it via government (or its equivalent) regulation. Very rarely do monopolies form on their own in free societies, and usually when they do form it is due to an abuse of the system and unless systemic corruption is maintained to support that situation (in which case, is it a free society?) then society tends to attack the monopoly resulting in either a curbing of its power or even a forced breakup. This creates a new period of opportunity and competition and the singularity is removed.

Sometimes a group comes up with an idea first, or figures out how to apply an existing idea in practical ways first, and due to this first-mover position initially monopolizes a given niche. In a free system this innovation is often very quickly replicated, or at the very least reacted to, by others and such monopoly is short lived. We can find endless examples in biological evolution as well as human technology for this exact process. This is also why the patent system came into place: this replication of good ideas in free societies can be so efficient that it makes it hard to profit from good ideas without some mechanism of protection.

(Aside: this implies that patent systems are only valuable when they reflect the real ratio of initial effort investment to reward rate.)

This is why most markets (economic, political, social, ..) have multiple competing parties. This competition drives everyone forward and reduces the risk associated with a single point of failure, which is socially beneficial. As a result, free societies tend to outpace societies with less freedom: by artificially enforcing singularities improvement incentives are reduced and risk associated with failure is driven up.

So whenever I hear someone say that their plan involves being "the only" thing in a free society, I assume they don't understand much about free societies. When this is coupled with adjectives such as "true" it starts to smell of fundamentalism.

Free software intrinsically exists in a free society: it is mandated in the licenses. The only ways around this are to artificially create singularities by monopolizing the talent pool (hiring all the developers) or keeping all decision making power in one central place that is guarded by veils of inscrutability and a lack of accountability. People who think this way are not the sort of people I would like to see directing free software; it is a recipe to curb the intrinsic freedom brought by free software.

Instead, we must embrace the sustainable and powerful forces of free systems, which includes diversity and competition and almost never being the "only" of anything that is usefully important.

Read More

like an avalanche coming down the mountain

Looking out over the countryside beyond the office windows and I see, finally, the first fingerprints of spring. With the turning of the seasons will come growth and renewal, making Spring perhaps my favorite time of the year.

When looking over the KDE landscape this week I was felt a similar Spring feeling in the air. There are new maintainers for Qt/KDE integration of PolicyKit and KMix. Sebas updated us recently on the huge progress being made for Plasma Workspaces 2, featuring a working shell on top of libplasma2 and QtQuick2. This itself is just a small part of the larger Frameworks 5 effort, and that is receiving more attention such as the recent sprint in Spain that Albert wrote about. Krita continues to amaze, Ingo has made a breakthrough in taming our web presence continuity and there is even work happening on Akregrator!

There were two other happenings this week that were of personal interest.

Bodega Web Client

First, was the announcement of the work-in-progress Bodega web client. Bodega is a little node.js server that Zack and I started so we could have a Free software content store. Since then others have pitched in including Marco, Antonis and Giorgos from the Plasma team. We have a C++ client-side library that speaks all the right json for you which we use in the Plasma Active add-ons client and now we have the start of a web client.

This web client is also written using node.js and can be easily run on pretty well any sort of device. Here is a quick screenshot of it running on my laptop:

It currently requires a redis instance in the background to store the session which makes sense for where scalability is required, but this could be made optional fairly easily. Otherwise, it's a simple matter of running `npm update` and starting `node app.js` (or if you prefer: `forever app.js`).

There is a significant implication here: you could pop this simple web app on virtually any sort of device, including ones with no screen attached, connect via your web browser and start browsing and installing content from a given Bodega server. One could also put this on a server to deliver content to machines connecting to it.

Imagine installing add-ons to your wireless router or the media box in the living room via the same interface that you get add-ons for your desktop system or your tablet. That's what we're building, and it's all Free software.

The web client has just begun, and so is not yet feature complete, but it is progressing quickly. The Bodega server is quite functional, but it too could use some feature additions. We're busy working on these things, but always remember that there is a place for you, too! If you have experience with node.js, web development or QML and find this concept exciting, you can find us online in #active on irc.freenode.net and the active at kde.org mailing list.

Plasma Media Center

We also saw the first release of Plasma Media Center, or PMC, this week.

Why does the world need yet another media center? On the one hand, it doesn't: things like XBMC are quite awesome. On the other hand, we have a specific set of requirements that isn't fulfilled by what was available and there was no realistic way to meet them with what existed without significantly altering them. Expecting other projects to suddenly change everything they were doing to meet our rather specific needs was neither realistic nor, I felt, very nice to ask of these other projects.

Our requirements were:

• A simple and clear, scalable user interface. It needs to work as nicely on a tablet sitting in your hands 40cm from your face as it does on a great big television sitting on the other side of the room.
• Integrate with Plasma workspaces: visually, in configuration and in user interaction patterns.
• Use the same technology infrastructure we do, such as using Nepomuk to populate the media
• Be able to integrate with online services
• Be extensible so thing additional features such as T.V. channel listings can be added.

During this time, there has also been the development of applications that hit a couple of these points very nicely, such as Bangarang which uses Nepomuk and KDE's libraries. These are primarily "window optimized" and we still need something focused on full-screen and alternative input methods .. which is where PMC comes in.

We want to be able to provide a consistent, full screen, simple media playback and exploration interface across the device spectrum .. and now we can. This will not replace Amarok, Bangarang, Dragon, JuK, ... nor could it without fundamentally adjusting the goals of PMC, which we obviously can't do while keeping to our goals. PMC is for when you want your device to focus on media consumption .. and that's it.

As is typical, PMC does not roll its own media playback but relies on Qt and underlying technologies such as GStreamer for this and it uses QML extensively throughout. I'll be talking more about PMC tonight in this week's episode of The Luminosity of Free Software, so if you'd like to see it in action and learn about some of the more interesting technical details tune in there.

Read More

Luminosity of Free Software, episode 8

This week's Luminosity of Free Software show will be recorded tomorrow on Friday, instead of the usual Thursday time slot. I have another engagement tonight, and it will be interesting to see how viewership changes, if at all, on Fridays.

Topics tomorrow will include:

• Plasma Media Center: .. or "PMC" as we lovingly refer to it, had its first stable release this week We'll take a peek behind the scenes to see what drives it. We'll also glance at it's goals, purpose and future.

• freedesktop.org Summit: If you haven't heard of this event that's happening in three weeks time, don't feel bad as it wasn't announced very broadly at all. I'll share with you what I've learned about the event and speculate on what we can hope to come from it.

• Lernstick: Not just "Bootable Linux on a USB device", but also a log in key that can automatically create the user on the stick and mount the USB device as the home directory. Pulling this off is trickier than one might think. I'll examine how this device designed for schools works as well as look at where it is in use today.

• Q&A: Otherwise known as "chaotic happy fun time" in which you ask questions and I do my best to foment further discussion. :)

See you there on Google+ Hangout tomorrow (Friday) at 20:00 UTC. You can watch the live feed (assuming all that magical hangout stuff decides to work) or afterwards at your leisure on my Youtube channel. I watch the chats in G+, Youtube as well as in #luminosity on irc.freenode.net during the show. Ask questions and offer additional information there.

Read More

logging into Plasma Workspaces 2

You're probably wondering what I was doing at 1am last night. I get asked that all the time. Well, mostly by people I live with, now that I think about it. "What were you doing on your computer at one in the morning?" they ask. The answer is usually quite exciting. Take last night, for instance: I was having a meeting with people to discuss display managers. Yes, the wonderful world of login screens.

We now have a truly amazing spreadsheet that tabulates the current state of three display managers. It has sections from community, "soft" attributes (such as licensing and build system), technology support, features and performance. Unfortunately, this did not lead us to any firm conclusions but it was very useful in helping better understand the landscape here, which is what we were after.

Our Requirements

The question we are trying to answer is this: What display manager will we use in Plasma Workspaces 2? Candidates must match a simple and clear set of needs:

• Must be lightweight. We want to use this on desktops and devices.
• Must be maintainable. (Self explanatory.)
• Must be able to write the user interface in QML.
• Must be able to be a Wayland system compositor.

How hard can that be, right? ;) Bonus points are awarded for things like:

• Used by other projects (co-investment and user consistency)
• Familiar tooling (we can always learn and use another revision control system, but we'd rather not as that raises the bar for participation)

Given that as a starting point we looked at three options and here's what my take-away on each was.

Contestant #1: KDM

This contestant is a deep soul with much complexity who likes things the old-fashioned way. 20 year old scotch is its drink of choice, and it hates walks on the beach (not much of a romantic, you see). It holds advanced degrees in many traditional practices. Let's say hello to .. KDM!

KDM does a lot of things very well. It is highly scalable (10k users in LDAP? No problem.), supports features such as remote log in, can be used with hardware and biometric keys and much more. It is themable, as a Google images search can quickly confirm. 

Unfortunately, there has not been much work on it lately and none of the active developers know the codebase very well. And what a codebase it is! 34,000+ lines of code, nearly 14,000 lines of which are C with the rest mostly C++. It is a beast. Interestingly, the KDM settings UI is 6,400+ lines of C++. That makes it's control panel nearly twice as big in terms of code count as the Plasma Active shell.

Work had been started on making a QML front end for it (twice, I believe) but it never came to full fruition, and it is unclear just how best to add a Wayland system comositor to KDM would be. So though it has served us well, KDM actually fails to meet our requirements.

Contestant #2: LightDM

This contestant is a young but accomplished fellow with lots of modern features. An outgoing sort, he strives to be useful to all around him and tries not to make many assumptions about what would make you happy. With lots of friends, he's seen at the entrance to many parties .. say hello to: LightDM!

With just over 20,000 lines of C code (though getting closer to 22,000 with the KDE integration bits), LightDM has a terrific number of features. It has a clear separation between the toolkit-agnostic backend and user interface providing front-ends that communicate via a local socket to get the deed done.

Guest login, auto-login, VNC/RDP/XDMCP, power management, fast user switching .. it's all there. Outside of a few things like biometrics, it has a superset of KDM's features. It also has support for new Linux middleware such as systemd and AccountsService, and does it all with a very small footprint (the daemon takes well under 1MB of RAM). It is also quite extensible and used by a large number of projects including the *buntu family of Linux distributions, RazorQt, Elementary and XBMC. 

There are three main contributors to the core LightDM according to the commit logs, all of whome work at Canonical. In addition to their efforts, David Edmundson's has been working on KDE integration for LightDM in KDE's repositories. Thanks to his work, you can write your UI in QML and PowerDevil is used for power management giving us consistency and portability. There is still work to be done, but it works rather well right now. I've been using it on my laptop for a while now, so that's not just theory.

A big piece of work that needs to be done is to add a Wayland system compositor. This is where things get tricky. LightDM is a Canonical project, and as such they will not be working on a Wayland compositor since they decided to part ways with the rest of the Free software ecosystem and create their own display system, Mir. One of our big questions was whether a Wayland compositor would be welcome.

Robert Ancell, the LightDM maintainer, attended last night's meeting which was extremely helpful. According to him, a Wayland backend would be welcome (though they won't write any of it) and there will be no hard dependencies on Mir in LightDM. This is reassuring, but means we need to trust the roadmap of Canonical a bit here and also means we'll be doing all the heavy lifting on the Wayland side. David has stepped up to do that work, however, which is also encouraging.

Due to LightDM being under Canonical's purview, contributing to it requires signing the Canonical CLA which is not acceptable to many developers (including myself) as it allows Canonical to take any and all code written that ends up in a Canonical owned asset and close it. This means that we won't really be able to contribute to core LightDM very effectively as a team. Some individuals may choose to do so, but several have already stated they won't, including those with the most experience with things like Wayland.

The fact that it is already widely used is a plus, however, as it means we may be able to share some efforts with others. This is particularly useful for system integration bits. For instance, Robert noted that Ubuntu will be working on logind support for LightDM. That said, some of our downstream distribution partners seem less than keen on supporting LightDM in their distributions.

So in summary: very featureful, relatively mature after three years of development, we already have a good amount of integration, but it carries risk due to community and commercial dynamics.

Contestent #3: SDDM

This young whipper-snapper is still wet behind the ears, as they say, and is still learning the ropes but she's fast and lean and sports a shiny approach to life. Let's say hello to SDDM!

This project is only three months old and as such is, by far, the youngest of the bunch. It also has the fewest features. However, with less than 2,200 lines of code it already provides the daemon/frontend duality with socket communication much as LightDM does and the user interface is written with QML. In fact, the entire thing is written in C++ using Qt and the code is very clean at this point. As with LightDM, it's memory footprint is more than reasonable.

It is an open, community developed project and has been picked up by the relatively new QML-based Maui desktop project. The use of C++, Qt, CMake and git make this a very familiar feeling to the code base for us Plasma hackers. The QML package structure is actually very similar to our own, and I understand that was not completely by coincidence. There is one main developer with two others who have made some contributions as well. This is fairly similar to the LightDM development profile, except that the contributors are not paid by the same companies to work on it.

As with LightDM and KDM, a Wayland compositor needs to be written for SDDM. It also needs to gain support for a large number of features it is currently missing, such as AccountsServices, guest accounts and a number of others. It does already support systemd and have some power management features. 

The biggest concern I have is the youth of the project. Will it continue to be worked on and mantained? Will other projects also adopt it as it matures? Only time can tell.  I am very keen to seen how SDDM develops over the next couple of months.

Conclusions

This is a difficult decision to make. KDM is not going to make the transition into a QML and Wayland world with us, despite it having served us well in the past. We need something to take its place, and we'd prefer not to start from scratch when there are good choices that already exist.

On the one hand we have the feature filled LightDM with three years of track record behind it, but which still needs work to make it do what we want, and which has a relatively large codebase that will be hard to contribute to. That said, David has already put a good amount of effort into the QML support for LightDM.

On the other hand we have a youthful, and thus largely unproven, SDDM which needs even more work than what we'd have to dedicate to LightDM but whose code base is very small, modern and uses familiar tools and which is developed openly. We won't need to do any QML work, but we will need more system integration features. With SDDM, there'd also be very limited (if any) opportunities to work with non-Qt/QML desktop projects.

If more projects interested in Wayland got involved with either LightDM or SDDM, that could tilt the scales as we would be able to share the compositor work with them. Personally, I'm torn between the open community and great code base of SDDM and the utility, maturity and wide usage of LightDM.

Read More

the case: brand

This is part of the "Case for KDE" series of blog entries in which I explore various non-technical aspects of KDE. What follows are my personal thoughts and observations rather than an officially sanctioned position statement by the KDE community.

I figured I would start with the topic of branding as it is a fairly simple topic .. a nice way to ease into this little adventure. It's also a topic that has been getting increasing amounts of attention in the Free software communities in the last few years as products become more successful, projects progress and more companies appear on the scene.

So where does KDE stand on branding?

Brand as Reflection

Branding is used to communicate a message to the outside world. "What message?" is the million dollar question. Some use branding as a way to project an image of what they wish to be, sometimes without concern about whether that is reality or not. Some use branding simply as an abstract identifier that says "This is us" without embodying a given message. Others use branding to reflect the core values and ideas that exist independently of the branding. I like to think of these respectively as image, identification and reflection branding.

(I'm sure professionals in the marketing space who specializing in branding are ready to choke me right about now .. ;)

KDE has elected for the sort of branding that reveals inner realities. This means that there is extremely limited pressure from the branding efforts to alter the core products, values or community. Instead the evolution of KDE itself puts pressure on the branding, causing it to adjust with time to accurately reflect what KDE is right now and the direction the efforts are heading in.

This is why a few years back we chose to no longer use the term "KDE" to refer to the software itself, but rather the community. KDE is the people. The things they make, all that lovely software, art, documentation .. those things have proper names. This is not where KDE started 15 years ago, but what it became.

Brand as Permission

Sometimes KDE uses branding in a rather unorthodox way: as permission. When we took the name "KDE" away from our desktop offering (now referred to as Plasma Desktop) it gave us permission to reconsider the relationship between the libraries, the desktop and the applications. Up until that point there were two recurring sets of tensions.

A growing number of application developers were actively trying to distance themselves from the name "KDE" so that people wouldn't mistakenly think that the attributes of the "KDE desktop" reflected on their work, or that you could only use their app in "KDE" (the desktop environment).

We also undervalued our library assets. They existed simply to let us write applications. We released them in one big lump along with our applications, in fact. This kept many people from using the libraries and tied us to some very uncomfortable release scheduling attributes in which we had to release the core platform with the desktop (and the applications).

When we reworked what the "KDE" brand meant we were able to find the path to resolving these issues and now we are looking at the next major release of libraries happening independent from the desktop or applications, allowing greater access to them, and our application developer community is stronger and more tightly connected than ever.

I think this is a fascinating, and very non-traditional, use of branding and shows that KDE understands that the words we use can shape how we think.

Brand Consistency

While there have been changes in the last years to the brand positioning, the KDE brand has also retained a core consistency: that unmistakable blue, the gear, the K .. the "KDE-ness" of the websites, release announcements, the public support campaign. We've even kept our mascots, Konqi and Katie, though they have evolved too.

As with KDE's products, the brand evolves in a relatively consistent line forward. This is critical for our partners and our users who really don't need to deal with constantly changing directions. This is simply another way that the branding reflects the thing it represents.

Brand as Collaboration

KDE isn't only about the KDE brand, however. We've seen some fantastic brands crop up from within KDE  over the years. Amarok was perhaps one of the earlier such brands, and these days it is joined by such names as Kontact, Calligra, Krita, Marble, Plasma and more. The relationship between the KDE brand and these brands is refreshing: KDE does not aim to control these brands nor inflict changes on them to "better reflect" KDE (whatever that would mean) or to fall into line with the desktop offering, for instance.

Rather, the various teams within KDE collaborate through social interaction to find harmonies as well as independence. This results in separately identifiable identities for each team, though they magically end up echoing unifying principles both visually and in content.

Modifications to the shared branding has also been done through a (admittedly slow) process of collaboration. This has preserve harmony over the long haul even during times of change, something people tend to dislike on an instinctual level.

As a result, we have a rather healthy valuation and respect for the brands internally. Companies are actively discouraged from trying to exclusively appropriate brands that were developed in the community. As a result companies around KDE that do use KDE branding tend to do so collaboratively with both the community and other companies, which simply opens more opportunities and lowers the risk of conflict.

It isn't all insular, inward looking work either. We have worked with downstream packagers in the past to do special editions of our wallpapers to fit their identities while echoing our upstream art direction. Which brings me to:

Brand Plasticity

When KDE has had to choose between communicating our brand and respecting the freedom of others to modify our work, we've tended to lean in the direction of freedom. That freedom has an interesting impact on efforts such as artwork: we try to create the most beautiful thing we can so that our partners have no reason to modify it much. Our art team has gone out of its way to create a stunning visual identity encompassing icons, widget theme, color schemes and even a font. They've even brought this identity to toolkits other than the one we use (Qt) so that when you run application written with these other toolkits the user still gets a consistent look and feel. Our visual identity is therefore preserved by striving for quality and by being inclusive.

This is an interesting, and positive, result of respecting a certain amount of plasticity in the branding.

Branding as Not Everything

There is a theme in all of the above: branding is not everything. It always bends to, and reflects, the things we consider as more important, to be of more value: community, technology, openness, freedom. This has undoubtedly come at a certain cost to KDE's brand effectiveness, but it also contributes to the sustainability of KDE's efforts in the long term.

.. because maybe .. just maybe .. branding isn't everything, and shouldn't be allowed to push and shove around the more important things. That is something I believe you can count on in KDE for a long time to come.

Read More

Luminosity of Free Software, episode 7

I've started prepping for tomorrow's Luminosity of Free Software show, in which the following topics will be covered:

• Decentralized online communication: This was suggested by a viewer in a blog comment last week, and I think it's an important topic. I'll be looking at this from three angles: why it is important, what has gained traction and what has not, and what tools exist right now with an emphasis on "real time" communication ala Jabber and identi.ca.

• Node.js: I've been using Node.js for a while and have found it to be an interesting approach to web services. This neatly fits with the first topic in some way, so what better excuse than to give a "50,000 foot view" of this rather cool project along with maybe making a case for why we should care about this stuff more on the desktop, too.

• Color management: Also a viewer suggested topic, this is another area of progress for Free software when it comes to graphics. We'll look at some of the management tools and what it does for the desktop, applications and people doing serious graphics work.

• Q&A: Otherwise known as "chaotic happy fun time" in which you ask questions and I do my best to foment further discussion. :)

See you there on Google+ Hangout tomorrow (Thursday) at 20:00 UTC. You can watch the live feed (assuming all that magical hangout stuff decides to work) or afterwards at your leisure on my Youtube channel.

Read More

extending plasma desktop scripting

The Plasma Desktop Scripting system allows one to add, remove or alter essentially any aspect of a running Plasma Desktop or Netbook shell at runtime using nothing more than javascript. This scripting system is used to define the initial setup you get when you log in for the first time, to provide configure updates and to provide user-friendly ways of adding new kinds of panels and desktop layouts. You can even write scripts interactively by typing "desktop console" into krunner.

Today I was asked on irc if one could extend the Javascript API at runtime so that instead of people writing scripts having to know how your applet works internally they could just call things like "awesomeWidget.setTheme('foo')" and have that do the correct thing.

At first I said "no" because the API is defined and managed by the shell and that's all C++ and there is no plugin mechanism .. but then about five seconds later I remembered that I had indeed added a plugin system. In fact, that is how the "New panel" menu works in Plasma Desktop. I even had an example on disk: org.kde.plasma-desktop.findWidgets. This is a small  desktop scripting template package with ~13 lines of Javascript that adds a findWidgets call to the API.

Here is how you use it in practice:

var finder = loadTemplate('org.kde.plasma-desktop.findWidgets');
finder.findWidgets("pager", function(widget, containment) {
    print("Found a pager with id " + widget.id + " in a " + containment.type + " containment with id " + containment.id);
})

Which gets me output like this on my laptop:

Found a pager with id 4 in a panel containment with id 1

The "big trick" is that the findWidgets package does not have an X-Plasma-ContainmentCategories entry in the metadata.desktop file which prevents it from showing up anywhere in the user interface. As a result, it is only accessible via the loadTemplate call when installed into share/apps/plasma/layout-templates/.

You can distribute layout template packages with your Plasmoids or other Plasma add-ons to allow easy (and future-proof) interaction with your add-ons from user written scripts.

 Such fun.

Read More

the case

Natural ecosystems are wonderful things full of complexity and beauty. There are few ecosystems on this planet that are occupied by only one or two species. Most are a complex meshing of variety, though it is not uncommon for there to be dominant species (numerically, positionally) within them.

Interesting things happen when you change an ecosystem, however. If you remove a species, particularly a populous one, it leaves an opening full of suddenly unused resources in its wake. This opening usually fills up quickly with other species, often creating instabilities that over time even out until the system reaches a new equilibrium. Change the environment in some way (more water, less water; more heat , longer cold; etc.) and previously successful groups may find themselves marginalized, once again creating opportunities for others to grow and proliferate.

An interesting example of this happened in the North America with the removal of wolves from regions by humans which led to deer populations exploding which led to eating more vegetation, including tree saplings, which caused a retreat of the forest, which changed the water flow and produced more grass land, which marginalized other creatures that relied on these features ... eventually a new equilibrium was found. As predators slowly made their way back into the ecosystem, the equilibrium shifted again.

There's another way of shaking up an ecosystem: evolution of new successful traits. Every so often a new very successful trait will emerge in one or more species that causes similar shifts in equilibrium. Dinosaurs, humans, .. there was  remarkable blooming of adaptation in the Cambrian in which life went from simple organisms weaving their way through algal mats to something more like we'd recognize today: predators and prey, armor, speed, carnivores, .. It was all invertebrates and shelled animals, but it was a significant shift.

Ok, what does this have to do with anything that belongs on my blog here? :)

Over the last couple of years, desktop Linux has being going through changes in the equilibrium of our ecosystem. Huge ones; and they are analogous to the biological phenomenon above. Successful projects of years past have faltered while new projects have emerged in a glorious array of colors and forms. There have been shifts in strategy and traits. There are vacuums within the market, and there are new comers who are doing great and reframing the question entirely.

This can be seen in the purchase, resale and renaissance of Qt; in the emergence of Android; in the difficulties some of the Gtk+ based desktops have been experiencing; in the arrival of new contenders that are tightly bound to specific distributions. This is exciting and presents opportunities .. and dangers.

Through all this, the KDE community continues on, pushing forward year after year, release upon release. New stars emerge, such as Krita, while veterans such as Kontact refind their mojo. The KDE desktop interface built around Plasma was shown to be the most popular in several polls last year, often with double digit gaps between it and the nearest alternative. Fifteen years and KDE is still going strong and adjusting, adapting, innovating, supporting.

The key to all of this has been community: the community of developers, the community of users, the community of entrepreneurs, the community of big companies that, together, support KDE and make it what it is. With that in mind, I will be writing a series of blog entries, to which this is the introduction, about the properties of KDE that make it worthy of such community support.

I am embarking on this journey for a few reasons:

• to explore these ideas in search of fresh insight
• to remind ourselves around KDE what is important so that we never forget and build on them rather than discard them
• to share with others who may not know about KDE and its products why KDE is deserving of their support

I will be covering a variety of topics, including:

• How KDE manages community
• How KDE works with businesses
• How KDE works with others
• KDE's take on branding
• Leadership and coordination within KDE
• How KDE innovates
• The technology niches KDE fills right now
• How KDE is primed to fit into the technology disruptions of the next decade
• How KDE has achieved long term consistency over its history

I don't know which order I'll tackle these .. I'll probably let the muse guide me there. In each article, however, I will try to present the past, present and possible futures relevant to teach topic. In doing so, perhaps others will gain more insight into what KDE is doing and, perhaps even more importantly, how it is doing so.

Ultimately, I hope that it will give some readers new reasons to support KDE in its efforts. In a sense, I'll be making the case for why KDE is a desktop community worth your investment of time, effort and support and why KDE technology is a terrific choice for the GNU generation.

My overall thesis will be simple: KDE is built on systems of sustainability which we can rely on for the long term and practices which encourage Freedom and openness in ways that fundamentally matter and reward all of us.

As always, feedback in the form of support, agreement, challenge, disagreement, questions and new observations are not just welcome but desired. The only ground rule is that we'll keep the conversation constructive in the process.

See you tomorrow :)

Read More

The Luminosity of Free Software, Episode 6

It's Thursday again .. and that means another episode of "The Luminosity of Free Software" in which I host a constructive examination of issues of interest to the Free software community. At least, that's the goal. :)

In this week's episode I will be discussing two topics before opening up the open participation Q&A session:

• Wayland: In this segment I will take you to the place where the x.org developers go. Yes, we'll be looking at the next-generation display system known as Wayland, what it does (and doesn't) do, the state of current development, it's relation to x.org and what it can mean for future Free software desktop efforts.

• Krita: A new shining star in the Libre Graphics constellation. Also, that there is a Libre Graphics constellation.

• Q&A: As usual, we will spend the bulk of our time discussing your queries. You can ask them live in the chats, or in the comments below.

You can watch the show live tonight in my Google+ feed or in my Youtube channel at 20:00 UTC. Directly after the show, it will appear on Youtube for viewing at your leisure and sharing with others.

See you there!

Read More

Plasmate 1.0

As you may have read on The Dot, we released Plasmate 1.0 today. I'll just quote from article to give you an idea of what it is:

Plasmate follows the UNIX philosophy of "do one thing, and do it well". As such, it is not a general purpose IDE but rather a tool specifically tailored to creating Plasma Workspace add-ons using non-compiled languages such as QML and Javascript. It guides each step in the process, simplifying and speeding up project creation, development, adding new assets, testing and publishing. The goal of Plasmate is to enable creating something new in seconds and publishing it immediately.

 We have been pushing at this bit of code for more years than I care to admit. I seem to recall hacking on the package model class at the Tokamak in Porto in early 2009. 46 different people have made commits to it over its life time, and it finally all came together.

We have Giorgos and Antonis Tsiapaliokas to thank for getting this bad boy finally out the door, however. They have toiled and tended the code base for a while now with one goal in mind: release .. and they finally reached that point.

So why another IDE? Simple put: because it isn't another IDE. From the start page through to the publisher, it is a "get out of your way" interface that is entirely workflow driven. You will not write the next great C++ application with it, this is quite true, but that's not its purpose. Everything that makes a great IDE like KDevelop or QtCreator "too much" when trying to make a Plasmoid or a KWin script is exactly why we made Plasmate.

You don't have to worry about package structure, or external previewers, or revision control, or how to import a Plasmoid from the online KDE Apps catalog ... it's all right there for you.

Super neat tidbit: you can write KWin desktop effects in Javascript with Plasmate too .. that's right, twiddle your windows by pushing hardware accelerated code around with Javascript. Yay! :)

Read More