[maemo-community] Council Nomination: Javispedro

Mon Mar 15 04:07:33 EET 2010

S P Yeager wrote:

> javispedro is a developer whom I believe participates and communicates
> with "engaged users" where ever they may be. He provides help to these
> community members regardless of the applications they use or are
> inquiring about. His contributions and the enthusiasm he displays in his
> posts on talk.maemo.org are refreshing.
> 
> Steve Yeager

Well, first and foremost, thanks for the kind words.

As I was telling on TMO, I have my own doubts about what I can bring to the
maemo.org table. I'm neither a N900 newcomer nor a old head, having been
in this community for about a year (since I got my N810) and unlike some other
candidates not having a strong OSS background. But hey, I can try at least.

So I happily accept the nomination. But solving world hunger will have to come
later, sorry!

Some points about me (I leave it to you to decide it they're pros or cons ;) ):
- Computer engineering student in Barcelona, Spain
- Owner of N900 and N810
- Developer of some game ports with some system stuff; this year I've finally
experienced the stress of having thousands of feature requests (and TODO items)
and not knowing where to start :)
- Only OSS-related meeting I've ever been to was the Barcelona Long weekend, so
not much experience here.
- I tend to read TMO and the mailing lists (using Gmane) daily.
- Before the NIT I was a PalmOS head (I find this bit interesting :) ).
- I am more of a conservative person myself (not in the average political sense,
though).
- I dislike traveling (but I was already thinking about joining the 2010 summit
before MeeGo happened)
- I don't mind chitchatting, and I have some sense of humor. 
- My spoken English is awful.
- Did I tell about my total lack of any organizational experience? :)

And my responses to Jaffa's very own "interview"
(which serves a bit as proposed goals, nice job!):

> Sprint process
> 1) Do you see any flaws in it, and how do you think it can be improved?

The biggest issue to solve when you have a set of volunteers is how to make
the most of the limited amount of time they are willing to contribute to a
project. However, instead of attacking this problem, one can decide to try
to increase this amount of time -- developers (and I guess most people :) )
tend to "always find more time" for tasks they like.

Lately, I've been interested in the Google Summer of Code, where students
can choose between a set of "suggested" projects or can propose their own. Each
application is individual, and even multiple students can theoretically work
on the same idea (but I guess this would be frowned upon by the organizations).
IMO this is the best way to match a developer (or "contributor") with their 
most beloved project. A person with initiative will feel free to start their own
similarly sized project, while a person without initiative will feel free to 
choose from the list (like me :) ).

Since it is my understanding the sprint process works similarly, I'm completely
fine with it. Basically, tasks to do get decided --either individually or on a
meeting-- and get written somewhere, where potential DOers can choose. 
Potential TODOs are already prioritized using the MoSCoW method, which is fine
(though an act of faith is required sometimes for the most boring tasks).

> 2) What are your thoughts on ongoing communication during the sprint?

I believe most communication should occur before and after the end of sprints,
but, of course, it's interesting that at least there's some kind of progress
feedback for tasks during the sprint. This feedback has to be as simple as
possible, so that ideally DOers are naturally inclined to fill it, even if the
only thing they have to say is "I'm avoiding working on this because it's deadly
boring".

> MeeGo
> 3) As we move from "day zero" to "day one", what do you think the
priorities for the MeeGo community should be?

IMHO, as a developer, I find that the priority should be defining what MeeGo
is. Some people still see it as just the next "bomb" Nokia will drop from above
(much like Maemo was to certain Nokia users), while on the other side few
people believe this could be like the Debian project (why not? It could be!).

Ironically, as of now, we are waiting for the first code drop from above (the 
"opening" of the repositories). Clearly, it's still early to determine if 
this will be a purely commercial project or a purely community based one,
but hopes are high.

Of course, if we want MeeGo to be a community based project, WE should be
answering what MeeGo is -- but I think that's out of our (or at least, my) reach
right now.

> 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?

Considering that most contributing community members seemingly approve MeeGo,
one has to expect that after a few years any Maemo community would be 
severely reduced. What have we learned with the Hacker Editions, with the 
Diablo SSU (which seems to be getting hotter now!)? Unfortunately, my experience
here is minimal but positive, since my N810 is still not old enough for me as 
a developer not to target it while developing, and also recently there have been
some enhancements to the Diablo Extras infrastructure.

So, we have an user, power user and "lone" developer base that constitutes 
what I call the "device" community. They're more interested in the N900 than in
Maemo or MeeGo. Talking about MeeGo to them is like talking about the iPhone to
them, UNLESS they have an upgrade path (as TMO has shown us). Either you provide
infrastructure for those in the new community (and yes, I'm talking about 
keeping the older OS repositories as long as there's demand for them) 
or they will be left behind.

We also have a power user, developer (they overlap), and commercial developer
base that's more interested in the platform than on the devices. They will
naturally follow "upstream" (Nokia/Intel) instead of settling in one device.
Those already ARE the MeeGo community.

To sum it up, the "platform" community has already moved on; as for the
"device" community, MeeGo or Maemo is just a name change (and thus, "moving it"
will be something not unlike a web server move), so, why not?

(heh, I love the light I just gave to the "us"vs"them" debate.)

> 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?

Clearly, you are already distorting the argument. For any good "take over
conspiration head", the theme change was only part of a more subtle series of
changes! ;)

Technically, it was a take over, so I wouldn't say anything. ITT under the roof
of a slightly more official domain name. Was there any disadvantage? Did
anyone from ITT flee? That would be more interesting questions to answer. I find
none of that happened then. We can still talk about hacking the devices, we 
can still criticise Nokia, etc. Where's the "excessive Nokia control"?

Does anybody believe any community member will flee if we "move" him, as long as
we provide the same quality of services?

For god's sake, just put the older vBulletin style as an option ;) .

> 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?

As I pointed, I believe it will eventually die (think 3-6 years). Until that
happens, it's most important to continue providing the required services. Many
developers from the "device" community will keep building their applications
as long as there's enough demand to compensate the expected complexity of
maintaining it (see this week's extras-cauldron list for examples).

So, objectives would be: to keep the complexity to maintain applications for 
older devices _at a minimum_ ("Make OS200X build" checkbox, keep runtimes
updated in extras for older devices), and to allow for a place where older
device users (and thus, demand) can gather, like older device boards.

> 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?

IMO, this is the most important part of maemo.org. Without the infrastructure, 
I would only see maemo.org as a glorified forum. Not killing any of the
infrastructure (and by infrastructure I also mean paid contributors, sorry
for being a bit Catbertesque) keeping older devices alive would be one of my 
priorities, as long as the demand is up and contributors can keep.

A good question would be: are the facilities going to be duplicated? I do not 
see unsurmountable differences between the would-be MeeGo infrastructure and the
existing Maemo one; would the future MeeGo community accept hosting OS2008 and
Moblin apps under the download section (for example), or we will have to keep
the different sets of services apart? Hopefully not, since it would be a waste
of (currently valuable) webmaster time.

> Community
> 6) How can we encourage more, and higher quality, applications for Maemo -
> and specifically through Extras?

The platform has suffered A LOT of important changes in the recent years.
Move to Qt, move to MeeGo. When I try to convince _anyone_ to develop for Maemo,
the biggest nuisance is that the platform moves too fast. To put things in
perspective, this February 2nd I was explaining a bit the platform to a
University lecturer I know, including Qt, Debian, the N900, etc. That VERY same
day I returned home only to find the whole MeeGo story developing itself. You
can imagine my mood back then :).

What would I teach if I wanted to lecture about "Developing for Maemo^WMeego"? 
They would find little documentation about the platform specifics (they all want
to use the accelerometers! send data through the ir port! 3d games! create
MANETs! -- mobile adhoc networks -- really, I've seen this!), and all
we currently have for them is ugly and device ultra-specific APIs. Still, this
is not entirely our fault, as we currently have limited standard APIs for these 
topics. But this is the OSS world, and a good (but far) objective would be to
try to create and promote them. Is Qt Mobility the answer? Time will tell.

Even if Qt IS the platform now, it basically has no "stable" support on any
device. I find things like MADDE steps in the right direction (I see "the
right direction" as "an SDK that I can download, install and double click to
open a GUI where I can type Hello World then click on Send to Device"). 
Encouraging and promoting those would be nice (BCN-style developer events need
its own section in m.o!).

Yet of course, it would be important not to forget what Maemo is, and it would
be nice if I will be still be able to port existing GNU/Linux desktop
applications (whatever the toolkit or language) to MeeGo with _reasonable_ (aka
not necessarily zero) effort.

And that's about it. Hope I didn't bore you to death! (and If I did, sorry, and
feel free to correct me as much as you want).

-- 
Javier