Security researcher Joanna Rutkowska and her company have lauched qubes-OS, an FOSS based OS focussing on security by virtualizing all dangerous processes in the system. For example, you'd have a 'work browser' container, a 'shopping browser' container, a 'game' container etc.
They all work together and integrate smoothly, although there are of course a few limitations and extra steps the user has to go through for now.
Why is this interesting, besides from the security point of view? Because Joanna and her team have used KDE desktop technology to run the qubes-OS desktop (screenshots here).
They have made a couple of modifications, and integrated the technology pretty deep. Sounds like an excellent reason to interview them and ask about the why and how of this choice.
Another thing which came up yesterday is this email thread. Joanna here presents a proposal to from now on securely sign released KDE software packages. It's very cool Joanna is actively working on improving security within the FOSS world and within the KDE community.
So who is up for contacting dear Joanna and getting an interview or article out of this?
I already have some introductionairy text (see above...) and a bunch of interview questions laying around - all you'd need to do is expand a bit upon it, send it to her, edit the results, maybe ask follow-up questions and post it to the dot editors team.
As usual: Your english is bad? No problem. You don't have much writing skills? No problem. You just need a little time and willingness to help out...
Who's up for this? Tell me - just send me an email (jospoortvliet on the gmail servers), or mail kde-promo at our kde site.
27 May, 2010
25 May, 2010
On working together
A chat with Armijn Hemel (during good food - Roti Kip) about contributing lead to this blogpost. Within the KDE community we have a large number of volunteers working in a variety of areas. Paul notes in his blogs how 'modularization of the community' can be dangerous when a bus rides over an important contributor. Luckily I haven't heard of busses doing that recently, but there are other matters in life which can pull away contributors. This hurts communities, and I think contributors should think a bit more about that.
Real life interference - think about it!
Unfortunately, leaving is something one rarely plans in advance. Most contributors want to stay involved, and still offer to take on work - they just don't actually have time for it anymore. This obviously makes planning rather difficult - as Armijn noted, being a volunteer doesn't mean having no responsibilities.
But does it mean you always have to do what you promised, despite real life? My take: absolutely not. I think people should be free - and have fun contributing (hey, KDE tagline!). It should not be a MUST. Sure, its good to take responsibility, and even the more boring tasks have to be done. I don't always enjoy what I do - but in the end, the good feeling which follows once a difficult or timeconsuming task has been completed makes it worth it.
Share what you do - work failsafe!
What IS important, however, is to tell others you can't finish something. And probably even more important: to make sure others CAN take over things you did in the past or you are working on right now. Failing the first can be annoying - it makes it important for someone to track what others are doing. I try to fullfill that role but it ain't always fun and it's certainly not easy. But it can be done, and it helps immensely if you keep me updated yourself. However, the second issue is far more troublesome.
It is important to keep in mind that people, including yourself, could leave at any point in time. New job, having kids, illness, family issues - you can't plan them (ok, maybe the kids). Make sure you're expendible. It's cool to be responsible for a great many things - but none the less it is important to involve others and keep the team informed by mailing or blogging about it. And use a wiki or other collaborative tools to keep the crucial information.
Information overload - don't go to far!
Note I say the crucial information, be careful with information overload. It's why I always advocate to keep plans simple, and start implementing a part of it before finishing large documents detailing what COULD be done. Writing down too much hurts as much as writing down nothing.
Say you have come up with a great way to do things different, better. You've read this great article about it, and now you want to implement it. So you start writing a great and complicated plan. Very cool - but what if you can't finish it? It is unlikely for someone else to pick it up - often these 'grand plans' are cool, but if they're not a team effort from the start, they die of once the initiator leaves it.
Besides, talk is cheap, work is what matters. And FOSS teams in general have limited resources - resources I'd rather spend on stuff which matters quick, is easy to keep alive and is easy to get involved in. Low hanging fruit, so to say. Sometimes I get comments like "don't chase people away" and such because I focus so much on what is seen as short term benefits. I'm sorry, but in the end, results count, not big bloathed wiki's. I'd rather have for example a mediocre webshop online and then in time have others contribute stuff than writing an amazing plan and then - nothing*...
Simple is good - and take care of the basics!
Simplify great plans. Often, doing a little makes a great difference already - and in time, if others are interested, you can go further. This is the release early-release often mantra. It works even in marketing, as I've often seen. If you want something done, a proof of concept will lead to much more input that just a 'I think X would be a good idea'.
Besides, great plans can take away precious resources from the basics. Things which need to be done. So, I sometimes might be seen as blocking new plans and endeavours. Sorry, that's not my intention. I just want things to succeed, and I've seen plenty of big plans fail... Which doesn't mean you should never start big things - but make sure a lot of people are behind it and want to work on it or it will fail.
The key - or what to do!
Often, the key to success is NOT a big plan, NOR even your own hard work - it's about getting a few others involved, motivating them, AND keeping them on their toes by checking up on them and keeping interest up. For longevity of a team, this is even more important. And it is far more fun to work with others. So think about that wen you want to do something great: involve others, keep them updated, and don't soldier on all alone!
* note that this example is NOT a description of how we're currently setting up a webshop - it's a random example, Justin is doing great to say the least ;-)
One more thing - I would say the number of active KDE promo people these days (compared to a year ago) clearly counters the argument that the pushing a bit against 'big plans' which I sometimes do is bad for building a dedicated team ;-)
Real life interference - think about it!
Unfortunately, leaving is something one rarely plans in advance. Most contributors want to stay involved, and still offer to take on work - they just don't actually have time for it anymore. This obviously makes planning rather difficult - as Armijn noted, being a volunteer doesn't mean having no responsibilities.
But does it mean you always have to do what you promised, despite real life? My take: absolutely not. I think people should be free - and have fun contributing (hey, KDE tagline!). It should not be a MUST. Sure, its good to take responsibility, and even the more boring tasks have to be done. I don't always enjoy what I do - but in the end, the good feeling which follows once a difficult or timeconsuming task has been completed makes it worth it.
Share what you do - work failsafe!
What IS important, however, is to tell others you can't finish something. And probably even more important: to make sure others CAN take over things you did in the past or you are working on right now. Failing the first can be annoying - it makes it important for someone to track what others are doing. I try to fullfill that role but it ain't always fun and it's certainly not easy. But it can be done, and it helps immensely if you keep me updated yourself. However, the second issue is far more troublesome.
It is important to keep in mind that people, including yourself, could leave at any point in time. New job, having kids, illness, family issues - you can't plan them (ok, maybe the kids). Make sure you're expendible. It's cool to be responsible for a great many things - but none the less it is important to involve others and keep the team informed by mailing or blogging about it. And use a wiki or other collaborative tools to keep the crucial information.
Information overload - don't go to far!
Note I say the crucial information, be careful with information overload. It's why I always advocate to keep plans simple, and start implementing a part of it before finishing large documents detailing what COULD be done. Writing down too much hurts as much as writing down nothing.
Say you have come up with a great way to do things different, better. You've read this great article about it, and now you want to implement it. So you start writing a great and complicated plan. Very cool - but what if you can't finish it? It is unlikely for someone else to pick it up - often these 'grand plans' are cool, but if they're not a team effort from the start, they die of once the initiator leaves it.
Besides, talk is cheap, work is what matters. And FOSS teams in general have limited resources - resources I'd rather spend on stuff which matters quick, is easy to keep alive and is easy to get involved in. Low hanging fruit, so to say. Sometimes I get comments like "don't chase people away" and such because I focus so much on what is seen as short term benefits. I'm sorry, but in the end, results count, not big bloathed wiki's. I'd rather have for example a mediocre webshop online and then in time have others contribute stuff than writing an amazing plan and then - nothing*...
Simple is good - and take care of the basics!
Simplify great plans. Often, doing a little makes a great difference already - and in time, if others are interested, you can go further. This is the release early-release often mantra. It works even in marketing, as I've often seen. If you want something done, a proof of concept will lead to much more input that just a 'I think X would be a good idea'.
Besides, great plans can take away precious resources from the basics. Things which need to be done. So, I sometimes might be seen as blocking new plans and endeavours. Sorry, that's not my intention. I just want things to succeed, and I've seen plenty of big plans fail... Which doesn't mean you should never start big things - but make sure a lot of people are behind it and want to work on it or it will fail.
The key - or what to do!
Often, the key to success is NOT a big plan, NOR even your own hard work - it's about getting a few others involved, motivating them, AND keeping them on their toes by checking up on them and keeping interest up. For longevity of a team, this is even more important. And it is far more fun to work with others. So think about that wen you want to do something great: involve others, keep them updated, and don't soldier on all alone!
* note that this example is NOT a description of how we're currently setting up a webshop - it's a random example, Justin is doing great to say the least ;-)
One more thing - I would say the number of active KDE promo people these days (compared to a year ago) clearly counters the argument that the pushing a bit against 'big plans' which I sometimes do is bad for building a dedicated team ;-)
02 May, 2010
Who is KDE part XXX
Hi all,
It's been a while since I posted a blog in the 'who is KDE' series (part 1, part 2). Meanwhile, there are of course still plenty of great blogs out there, and the ones I described last time might be worth revisiting.
This blog was prompted by me bumping into our cool buzz.kde.org site (which, btw, doesn't work properly in Chromium? Back to Konqi then..). A tweet in there pointed to this blog, in Polish (google translate here). It reviews a SVN version of the 4.4 release, mostly focusing on plasma stuff. But there is also news on KWin, Marble and Dolphin. My only gripe is that the author calls it Desktop Envirionment still - maybe I should comment on that ;-)
Now that the GSoC students have been chosen (see Lydia's blog, a dot story is in the making) Planet KDE is flooded with blogs from excited new developers who've been selected. I think it is incredibly cool to see there are quite a few from outside the traditional EU/US area - we've got two GSoC'ers from Peru, 11 (!) from India and of course a few Brazilians.
Planet India currently only has a blog from Akarsh Simha announcing two students for KStars but I also see two Pardus projects there, which most likely build on Qt/KDE (and Python) as well.
Planet Peru meanwhile shows our student Ronny has been active with more than his GSoC proposal (read how his KDE life started) and it seems the Peru FOSS community is pretty active. I found this page about a government bill about FOSS from 2002 when googling - it seems the government supports FOSS as well. I'd love to hear more about how that turned out so I'm glad Ronny is now on planet KDE ;-)
The growing diversity in our community brings more fun and more creativity, so I welcome it. I'm awaiting a few GSoC students from Nigeria - after reading the final report from Ade about the conference there I have high hopes... But for now, I think we're looking at a very successful Summer of Code, and those who aren't in yet: you can join the Season of KDE project, where despite the lack of financial compensation you will get the same guidance and some cool (Kool?) gear! Lydia is also still looking for mentors, btw. If you would love to do KDE Promo things, I hereby offer my services as mentor!
Oh and talking about promo I have some good news since my previous blog about some tasks for KDE promo: our new KDE e.V. intern, Torsten Thelke, is working on the boothbox! Points for Torsten ;-)
But there is still much more to do, including some layout work on a booklet for which we have text but still needs printing... Contact me if you would be able to do that. And the 'would be able' is more about time and effort than about skills, as usual!
Let me finish by giving a big thank you to the people active in the Indian community and in South America for bringing us some great new GSoC developers and for Being KDE! And good luck to all the new developers - kick ass!
Love,
Jos
01 May, 2010
A quick one on Being Free
Just finished editing a dot story on Choqok (will go live sometime next week). Some of you might have noticed the initiative by its main developer Mehrdad Momeny to speed up development by soliciting monetary input. This will allow him to spend more time on making Choqok rock, but also give users a tangible way of influencing development priorities. This can increase commitment from the users, developers and the community - while bringing real benefits (in terms of code).
The KOffice developers recently did a similar thing, calling upon individual sponsors to help make Krita better. Instead of taking a summer job, Lukáš Tvrdý spend time writing a series of improvements. As you can read on the Krita website it was a great success.
It is good to see initiatives like these. With our growing ambitions and plans come growing requirements for resources. Traditionally, the KDE community has relied heavily on volunteer efforts, and this won't change. However, it is important that developers look for ways to be able to spend more time on doing what they want. Some find employment or start up companies, others look to those who want to contribute in other ways than with their own time. I believe diversifying our resources means a more sustainable community, which ultimately benefits our plans for world domination ;-)
Next time I'll blog more about Being Free, continuing from here. I'll also try to touch on the recent discussions about paid vs unpaid contributors where Zonker participated in.
The KOffice developers recently did a similar thing, calling upon individual sponsors to help make Krita better. Instead of taking a summer job, Lukáš Tvrdý spend time writing a series of improvements. As you can read on the Krita website it was a great success.
It is good to see initiatives like these. With our growing ambitions and plans come growing requirements for resources. Traditionally, the KDE community has relied heavily on volunteer efforts, and this won't change. However, it is important that developers look for ways to be able to spend more time on doing what they want. Some find employment or start up companies, others look to those who want to contribute in other ways than with their own time. I believe diversifying our resources means a more sustainable community, which ultimately benefits our plans for world domination ;-)
Next time I'll blog more about Being Free, continuing from here. I'll also try to touch on the recent discussions about paid vs unpaid contributors where Zonker participated in.