[maemo-community] Council Nomination: Attila Csipa

From: Attila Csipa maemo at csipa.in.rs
Date: Tue Mar 16 03:36:19 EET 2010
After much thought, I have decided to accept the nomination and am announcing 
my intent to run for Council.

A short introduction: I'm a software consultant specializing in OSS 
technologies by day and Open Source hacker/language geek by night. Formally, I 
hold an MSc in Electrical Engineering and Computer Sciences, am a bilingual 
Hungarian/Serbian and get along in a number of other languages. I joined the 
Maemo community ranks in 2008 when I (almost by chance) acquired a N810, and 
was almost instantly taken by the possibilities, both of the Maemo devices 
themselves and the already formed community around them. I'm fairly active on 
talk.maemo.org (under the attila77 alias) but also follow the mailing lists 
regularly, with occasional visits to IRC. In developer waters, I'm mostly 
known for my activities relating to Python and Qt (which was also the object 
of my talk on the last Summit), but am also a member of the Testing squad and 
have a dozen or so applications and libraries in the repositories (like 
AppWatch, QuickBrownFox, PyQt, support libraries for Easy Debian on Diablo, 
etc). While I have a strong developer background, I emphasize general 
community involvement just as much, embracing and cherishing the unique mix 
the Maemo community is, and hopefully the MeeGo community it will become. More 
on that later.

Now, for the "questionnaire for Council candidates"

>Sprint process
>This is the main organised point of contact between Nokia, the paid
>contributors and the community, however the maemo.org sprint process
>is quite heavy for volunteers and it often seems to be a checklist
>affair; rather than a collaborative planning exercise.
>1) Do you see any flaws in it, and how do you think it can be improved?
>2) What are your thoughts on ongoing communication during the sprint?

I see the two points as one, mainly the question of efficient communications 
and information flow. Every council must find the way to address this, both 
technically (whatever is necessary to allow collaboration despite different 
time zones, schedules, etc). The exact measures to do this will depend a lot 
on the actual composition of the next council, and that's why I think it's 
very difficult to propose solutions for anyone without knowing how other 
potential council members and maemo.org staff or volunteers feel about them. If 
the interested parties can come to agreement, it will work, if they don't, it 
doesn't matter how good the proposition sounded on paper. The bottom line 
within the sprint itself (or the council, for that matter) is not simply about 
procedures, it's about having an overview of what's done, what's going on, 
what's feasible and what can be expected to provide the best possible outcome 
for the community. 

>MeeGo is, IMHO, the single biggest thing to happen to Maemo since the
>770. In many ways, it's the opening up of the design processes that
>many of us have wanted in Maemo for so long. As Maemo as an operating
>system disappears, this will have a big effect on the community.
>3) As we move from "day zero" to "day one", what do you think the
>priorities for the MeeGo community should be?

The MeeGo community currently reminds me of a confluence of two rivers where 
even though the rivers continue to flow in a single riverbed, but are still 
very coherent and have not mixed at all. There are technical and 
organizational tasks to do, but a many of these are still in limbo with a lot 
of people just feeling their way through the new structures. As we have very 
little of the tangible things to talk about, and the aforementioned community 
structures have yet to form, the MeeGo community priority is IMO to prepare a 
solid basis that can accommodate the existing communities. There are already 
mailing lists, and some budding cms/wiki efforts, but these need to be more 
coordinated and with a clear goal of how and when will they merge/take over 
the role of their original Maemo/Moblin counterparts. With still a lot of 
mystery over how MeeGo will actually function, and the fact that it's always 
difficult to start filling an empty page, this is no easy task, but needs to be 
done right in order to avoid wasted efforts, chaos and fragmentation down the 
road. This will require more (and continuous) involvement from all MeeGo 

>4) Should leaders in the MeeGo community (whether from a Moblin or
>Maemo background) try to move the existing communities with them to
>form the MeeGo community; or should a new community form around the
>operating system and its devices?

Communities are not formed around announcements. As exciting the news itself 
might be, the real tectonic movements in the community will happen when 
devices start appearing, until then, it will be mostly developers dipping 
their toes in the first builds. Knowing Maemo history, the community has been 
reborn like a phoenix from it's ashes several times, and in a way, this is 
what is likely about to happen again. Considering the Qt4.6 connection, and 
the N900 being a reference platform for MeeGo, this shockwave/change might be 
even smaller than it was in the N8x0 -> N900 step. However, the real magnitude 
will be reflected in the following:

>4a) If yes, what steps should be taken to prevent overreactions and
>allegations of "take over" that happened when internettablettalk.com's
>theme changed to match the rest of maemo.org?
>4b) If no, how do you see the relationship between the Maemo community
>which has been "left behind" and the MeeGo community? How does the
>Maemo community stay vibrant if large portions on moving on to Maemo's
>successor, or drifting away to other mobile platforms?

I think we are maybe already late for this. I'm really sorry to see that even 
though we are in theory given a carte blanche, there are already some stones 
in motion which have already caused growing pains even before day one. For 
example, QGil stated they see meego.com as the "new home for this community" 
and that they are working on it (community participation welcome). While I 
have no doubt Intel and Nokia wish the best the to the MeeGo community, it 
does come across somewhat awkwardly (if it's our choice, our new home, and we 
certainly have a fair amount of very capable staff... participation sounds like 
an understatement). There have already been skirmishes on talk with regard to 
forum software and CMSs. I think it is of the utmost priority to come up with 
solutions that will preserve the community and do it BEFORE the majority of 
users gets caught up in the turmoil of new releases and devices. It's a very 
organic thing, and a new home is of little use if we never make it over there, 
or, worse yet, if the community gets ripped into two in the process. We need 
to find a solution that provides a stable migration path for everybody - users, 
developers, forum folks, mailing list folks, etc. The timeframe in which I 
expect this to happen will probably mean that this Council's role will be 
mostly preparatory, but I think that's just as important. Do not take me wrong 
- I have no intention of barging into the Moblin camp and tell them what to do 
(and I expect the same from them, even though a few things are already taken 
ad acta on meego.com), but we must find long term solutions that will not only 
accommodate but integrate both communities if we wish to keep and leverage 
what we had going on maemo.org. There has been already some collaboration with 
regard to OpenID and SSO, and that's IMO a good direction that should be 
continued and expanded on.

>5) What are your thoughts about existing maemo.org resources (such as
>Extras, auto-builder, Bugzilla) as Nokia, and the paid contributors,
>look to the future?

These resources are probably the most precious one (for the developers 
certainly, but I daresay for the Maemo platform as a whole, despite the 
occasional headaches caused by downtime). Extras provides 90%+ of all software 
available on the Maemo platform, and not only as a download center, but as 
complete infrastructure. Obviously, in some form, it MUST continue to live on 
as it is the lifeblood for generations of previous Maemo devices, and for the 
N900 in the foreseeable future, too. Things will certainly change as MeeGo 
means serious differences in build mechanisms (OBS, etc), but sadly we know too 
little of the details to make any serious migration path, which will certainly 
be an important point (I saw Jeremiah pushing for more info on this, kudos for 

Two points in my short term agenda I wish to discuss further and hopefully end 
up with a result that improves on the current status of Extras-*:

1. Continue streamlining Extras-testing procedures. It *does* work, even Nokia 
acknowledged this by enabling Extras by default. It *isn't* as painless as 
planned initially, though. We must continue making this process as painless 
and efficient as possible for the developers. It's not about simply discarding 
faulty software or playing a game of exhaustion, it's about protecting end 
users, giving feedback, advices and helping development at the same time. 

2. Explore the possibility of introducing PPAs, and push for introducing them 
if they prove a viable path. For those not familiar with the matter, PPA's are 
personal package archives. We already know from the pre-Extras era that a 
large number of scattered repositories are a recipe for disaster. PPA's solve 
this by building on top of the main repositories (Extras or Extras-devel in 
our case), having full sources and sharing the same procedures with Extras-
devel without polluting Extras-devel with packages that are temporary or not 
intended for anyone not specifically interested in them. Less breakage, less 
wasted space and bandwith, less binary abandonware, less sad users.

That would be it, in short, I plan on expanding on the points mentioned during 
my campaign and hope to have meaningful conversations on these topics with 
other Council candidates in the upcoming period. Thank you for your attention 


More information about the maemo-community mailing list