This blog entry describes what national MeeGo network is and what it could be. Viewpoint is  teams which are the core of any community. Introduced model is  a refined vision or version which has been build through the experiences in Finland (MNFI). The model described here will not be the last. It is natural for the community to stay constantly on the move. Still some teams are more ’sticky’ than others and that is natural. This stickiness is discussed briefly. The model is not constructed entirely from my own thoughts. A lot of MNFI members (and some others) have been involved by creating practices and guidelines. My role in this is to gather things together and raise some discussion (hopefully). I own my gratitude to all of you, but to name a few cybette, jnwi, timoph, smoinen, Riussi, Ans5i, matrixx, sandst1, bergie, Stskeeps and jibun.

Why teams and not groups?

Before taking a look at the initial teams in MNFI, one might be wondering why I prefer to use the word ‘team’ and not for example ‘group’? According to some scholars and other thinkers, groups are formed before teams. Groups are loose networks or collectives and teams are in fact first only groups. But if things go well, group becomes a team which is more cohesive unit, possesses complementary skills and abilities, share a goal and are committed to achieve that goal. Of course this might sound like pure semantics, but it’s not. Another difference between teams and groups is leadership. In groups leader or leaders define the goals and members are willingly accountable to leader(s). In teams, members hold each other accountable and try to reach consensus on goals and how to approach identified goals. Yet another difference is found how groups and teams handle conflicts. When conflicts arise in group – for example someone is not performing as expected – members look for the leader and expect him/her to act. In teams, members approach the person directly. Final difference I wish to expose is related to decision making. Groups use commonly voting or implied agreement. Teams prefer to use consensus. There are other viewpoints to this, but I will not address those here.

At the global level MeeGo community uses the term ‘working group’. That’s fine, if you are not anarchist and hard core FOSS like me. The word working does not fit in unless you are participating MeeGo related activities as paid staff. Even though I get paid to be community manager, the word still pushes my away. Team as a term is more casual and loose enough and it fits the purpose (at least in national level) which is to get people committed to community.

I would also like to see a clear division between teams and task-forces. Teams are something that are sort of sticky; teams live longer and have more general nature in community. Task-forces are small groups, which are established for special purpose and live only to gain a specific goal. After the goal or goals have been reached, it is disassembled either for good or for some time (for example Program Task-force).

The initial teams

Our national network has been around for about 4 months now. I did have a vision of national level MeeGo network in the early stages, when I started to co-host Tampere MeeGo Network (TMN) meetings with Myrtti. I posted my vision to newly established TMN mailing list with topic: ”I have a dream”. Cheesy and worn, but it says exactly what it was, a dream.  The mail (Oct 25 2010) started with the following:

I’ve had this idea in my head for a week or so and it’s time to spit it out. I can see that a sort of community portal would be needed in the future. The portal would aggregate several info streams and possibly offer some tools for the community. By community I mean MeeGo Networks in Finland. The portal would serve as a single entry point to all local networks, MeeGo related events and activity in Finland.

In the beginning (Oct -Sept 2010) there was nothing more than Tampere MeeGo Network and lost wannabe community manager, which also co-hosted TMN meetups. At the same time Helsinki, Turku and Jyväskylä also started to organize activities. As far as I know, just Helsinki and Tampere have been active since that, but I might be wrong. After we got TMN up and running, the idea of national events matured. After a while,  foundations for the national community were defined when 6 teams were established:

I did not select pieces of puzzle by accident to describe teams. Building community from teams is like doing a puzzle. Sometimes pieces fit perfectly, sometimes not and justified forcing is needed (not necessarily by the manager). Some pieces are connected to several other pieces (gain more focus or have more activity) while some stay near the edge of the board. Unlike in puzzles, the pieces of community can overlap slightly. Too big overlapping in tasks and responsibilities will create disorder and can cause ‘territorial disputes’.  Of course community must be open to new teams or new combinations of existing teams. That’s why there are holes and hooks on the edges of pieces. I could discuss the group dynamics of teams, but it would be out of scope of this entry. Better save that for later.

Right from the start, some members of TMN jumped into teams (which were at first groups). In October some interest towards national co-operation raised in Helsinki. In December Helsinki MeeGo Network (HMN) joined newly born MNFI. This moment can be said to be the real birthday of MNFI. That moment was 1st December 2010 when HMN had meetup in Helsinki and I visited there to tell them about our (TMN) visions related to Summit and national community. Response was good and some joined immediately. You can read more about the early stages of MNFI from previous blog entry.

Let’s take a look at (just briefly) the early teams illustrated in picture above. First of all, it’s a colorful bunch :) Team names have hardly anything constant. One team is called task-force, one does not include the word team and rest are teams which varying prefix. It is said that some amount of formality and uniformity in naming structures is good. In this case, that was not followed. One team name includes even MeeGo community specific jargon (meegons). That name used inside our community is fine, but for the outsiders, from where new members come, it might seem a bit odd and puzzling. Who should we blame for this mess? Well, yeah, no other than me. I have been involved in some communities before and some ideas came from those experiences. Furthermore, since I’m a researcher I read some books and other writings. One good book for every community builder/enabler/manager is  Jono Bacon’s The Art of Community. It includes basics to get you started, but remember that every community is a bit different and you need to adjust those ‘advices’. And that is what I’m doing now, adjusting the model to fit our needs and situation.

MNFI teams were established while keeping two things in mind. First, we planned MeeGo Summit for the spring and teams seemed natural tool for that purpose (clear goal which everyone agreed on). Second, some teams need to stay alive after the summit and form more constant basis for community. This blog entry tries to take a look at life after MeeGo Summit FI, so the focus is on ’sticky’ teams.

Communication & Tech team

This team (for the sake of clarity let’s call it C&T) is responsible our server, national level mailing lists (freenode and meegonetwork), irc Ops and controls our own domain. Freenode is our national level mailing list provider. We use meegonetwork domain for team mailing lists and mail addresses. In other words, C&T is rather tech oriented and looks a lot like company IT department. Before the redistribution of tasks between this team and Marketing team, social media related tasks were sort of ‘no mans land’. Our national level social media were handled by me and smoinen.

C&T lead handled (and still does as far as I know) Tampere MeeGo Network Facebook page. Same lead also manages the LinkedIn group. This is something that is not consistent or clear in our practices, since Marketing team is supposed to manage all social media related services. This will be discussed below in details. This overlapping is an example of previously discussed task overlapping between teams. Even though it might look inconsistent or illogical, these overlappings or sneaking in other team’s ‘backyards’ normally does not matter as long as everyone knows about it. Besides we are not a big community, at least not yet so information spreads inside our community mostly from person to person. People seem to prefer personal communication over posting to national mailing list. This observation is based on the facts that MNFI has around 250 members (based on Meetup.com) and a little over 30 have joined national mailing list. Even our IRC channel (#meego-fi) has more people (over 50). Meetups are also one communication tool, since a lot of issues related to MNFI are discussed there, partly because I have reserved 15 minutes for my self in some of our TMN meetups.

Program Task-force

This team was established to take care of Summit program. Tasks included among others things to define the structure, gather ideas who should be the speakers (and then invite or approach selected candidates), what kind of tracks there should be, where the tracks can be placed and what other activities there could be. This team was based on inviting suitable community members to it. In other words, it was not open team. A of lot ideas regarding the Summit content came from community. Even though the team had responsibility to take care of the program, several community members were involved. For example, a great deal of the Meegathon competition definition was result of community work.

Marketing team

Marketing team has been (or still is) one of the most popular teams. Several members are involved in it partly because it includes a wide variety of tasks from simple leaflet distribution to graphical design. Moreover, the members in this team are highly active. This team is open, meaning that anyone is welcome to join it. Marketing team was previously more oriented to print media and  constructing marketing material such as leaflets, posters and t-shirts. They handle the whole process  from the start to distribution. This means that they design material, contact printing companies, get the prints and organize distribution. In other words, marketing team acts as quite independent unit. Of course they ask opinions from rest of the community, but they do decisions (in marketing issues). Tasks and role of this team has changed lately, but I will address that later.

Hosting team

Team’s duties include comprehensive management of items which affect speaker’s enjoyment. Such items are for example arranging hotel rooms, providing information and assisting in session preparations. Managing pre-registration and registration (including portal) is one of the key responsibilities of this team. Hosting team also takes care of Summit information desk, updates program during the event, tweets and assists Summit participants in various situations. In brief, they are the human touch or face of Summit organizers. They are the people to go to when you have lost your precious laptop, netbook, N900, tablet, shoes, coat, Tux/MeeGon figure or hacking buddy. Information desk is also the correct place to inform the organizers about different activities which summit participants are encouraged to arrange at the venue. Such activities include hands-on sessions for small groups, unconference/barcamp sessions and workhops (or in this case hack-shops).

Hack3r team

To be labeled as Hacker is an honor among us. The word hacker means to us the same as ‘Sir’ does for the royalty. Members of this team are talented in different technical areas and posses deep knowledge. They are not so interested about anything that involves maintaining systems. Instead they are true explorers and tinkerers, always looking for new tech to try. Team members are not overwhelmed in front of technical problems and can think outside-the-box to find solutions.

This team has been responsible for defining ‘developer USB- stick’, which will be given to all Summit participants. That stick will include lots of tools for MeeGo related application development from various sources. The main idea behind this stick is to cut down the need to download all tools at the venue. Furthermore, it will hopefully serve participants’ needs also after the summit.

Party MeeGons

This is probably ‘teh’ team where the party animals join. Members of this team are true multi-talented entertainers; VJs, DJs with ideas for stunning laser shows. Parties are important part of any summit or conference. Because our Summit is developer and hacker oriented event, we do not want to offer our summit participants fancy dinners at mansions or rigid and boring wine tasting. We prefer to have more casual and relaxed parties, which can include ad hoc competitions and shows.

Part of this team’s work is to find location for the party and negotiate necessary issues with facility provider. They are also encouraged to find opportunities to have joint parties with other developing and hacking oriented communities. Also getting a sponsor for the party is important and one of the tasks. In other words, this team is given quite free hands on how the parties are arranged.

That’s enough about the initial teams. You can read more about the teams from previous blog entries (for example about Program Task-force). That was the situation for a few months. Things started to change (in my mind also) around Jan-Feb 2011.

Something old - something new

In February 2011 Marketing Team lead and Communication & Tech Team lead had discussions in which they agreed that some of the tasks need to be redistributed. My initial response was:” This is great! Teams start to behave as teams and define own nature and ‘borders’.” This showed also another important aspect of good and vibrant community. This is how teams and community should work: share ideas and work together as community between teams at least in team lead level. Of course sharing ideas and information between teams in general (including member to member) is highly necessary, even more than in lead level. This is why the importance of fluent communication is highlighted in my new model below.

The need for fluent communication is nothing new to those who have been in communities for some time, yet it is sometimes necessary to remind about that. In the figure above, communication is taken ‘away’ from Tech team. This change should be understood figuratively. Lets take a closer look at communication and the teams.

Communication

Tech Team is still responsible for technical items related to communication. Reason why the word is separated, is that communication is everyone’s responsibility. Simply follow the rule: tell others what you are doing, if you want others to participate or it affects other parts of community.

Tech team lead (cybette) created a marvelous acronym and guideline for the team leads to follow. Team leads are given more responsibility in communication. In our community team leads have been given permission (username and passwd) to use our ping.fm service through which we push information to various social media tubes such as twitter, facebook and linkedIn group. Pushing is mostly generating bigger knowledge about us among the possible new members ie pushing a story out to the marketplace. At the same time we are pulling people in. Pulling is here understood as “focus[ing] to all the ways we use content and the web to pull attention and discussion in.”[source]

Enough with the social media and back to communication. Cybette labeled the guideline as D.S.P!

1. Discuss,
2. Share and
3. Ping!

Issues are first discussed inside teams or in other appropriate collectives. Ones some kind of opinion or proposal has been reached, it should be shared. Sharing can take place for example in our mailing list. The third step is to push information outside, not to keep it all within ourselves. This kind of model is simple and easy to remember. All this has been our practice for some time now and it’s part of the old.

Instead, what is new in this model, is the emphasis on social activities. Of course one can argue that MeeGo networks exist to do system and software development and innovations. This is true, but limiting one’s view to that neglects the other significant strengths of MeeGo ecosystem, namely social events.

Event Team

Having real world meetups - preferably monthly - are unique features of MeeGo ecosystem. Ubuntu or Android community does not have similar meetups. The closest thing to regular MeeGo meetups  are hackerspace events. More about hackerspace you can read from my other blog and from previous blog entry which compares MeeGo networks and hackerspaces.

This unique feature which differentiates us from other Open Source ecosystems affects our community structure and practices as well. We need ‘event team’. We need a team that coordinates our national level events and acts as a context to discuss issues related to monthly local meetups and other social events in local (cities) level. In other words, this team would be the core Summit organizing team. The other aspect - organizing meetups - is discussed below in details.

This team includes the previously discussed Hosting team. I would bring meetup organizers (and co-organizers) to this team. Until now, their important role has been neglected. They have existed, but without any clear position or context in our community. This is partly understandable, because in our community local MeeGo networks are independent from the national body. Still, remaining independent they should be part of our core activities.

Meetup organizers

Let’s take a look at what meetup organizers do, why they are valuable and why they should be included to ‘event’ team. Five duty areas can be identified: general level meetup organizing, sponsor negotiations, meetup promotion, inspiring and activating members in local level, and starting Summit preparations and acting as core Summit organizer team.

1. Organizes meetups

Well, obviously they are responsible for the meetups. This means finding locations to hold meetups, print the nametags, makes necessary arrangement with facility owners, is our local contact person and face to outside world. Concerning the space, best option is to get fixed location which has enough space and at least adequate setup for presentations. Otherwise you might end up running behind the sponsors instead of making them come to you.

This also includes sketching agenda for every meetup. It does not how ever mean that organizer should generate topics for presentations. Instead he/she should encourage members to suggest presentations and collect those as agenda. Tool for this might be local mailing list, as we have in TMN. Mailing list also helps to keep members informed about different issues and fosters activity even between the meetups. We have used meetup.com services as well. It has been the main tool for organizers. Yet our intention is to get rid of it as soon as possible. Not that it’s completely screwed, it has some features that are not as good as they could be. We will implement similar (yet improved) service in our national level portal.

2. Negotiates with sponsors (others help to get)

Often sponsors can be easily found or persuaded to take part. At least in Tampere, sponsors have been interested to be part of us. Previous sentence expresses the way I see sponsors’ role in our community. They are not ‘others’ somewhere outside the community. They are part of the community. We should listen what they say, but not loose our ability to remain independent. They must also know that they are seen as part of the community.

3. Takes care of meetup promotion

This taks is part of our marketing and communication. Putting our events to meego.com events list, the world around us can see that we are active and alive. Listing events can also attract new members. Adding our events to meego.com events is also one form of communication towards global community. By doing so, we tell rest of the community that ‘hey! We are here, we are plenty and we do interesting things!’ We have been adding our events to vapaasuomi.fi calendar too, but that is somewhat too laborious and it has been neglected lately. It would be a great place to put info, since it distributes event details for example to ubuntu-fi.org’s frontpage.

4. Activates members to contribute

Meetups need presentations, demos, implementations and permanent or casual co-organizers. Meetup organizers should be innovative, explorer like personalities. They should be bold in ideas. They are supposed to inspire members with different ideas. Let the members act as filters, they will tell you whether your idea is mad, insane, impossible or great, inspiring and a little from outer space. Flying drone is an example of such goofy idea. We tried that in Tampere and right after that in Helsinki. People talked for weeks about that presentation and drone flying around. It even inspired some members to start developing new application to drone.

5. Start Summit preparations

Main responsibility to get annual summit preparations going (includes building necessary teams). and meetup organizers are supposed to work together. Why put Meetup organizers to begin Summit organizing? First of all, they are at least monthly in touch with the people in our cities where meetups are organized. They hear what is interesting, they discuss with a lot meetup participants. Secondly, they know the facilities in their area probably pretty well. Thirdly, they are constantly in touch with local companies (which are commonly also multinational) because of meetup sponsoring. In brief, they are are extremely well connected people and they should be encouraged to be so.

Of course meetup organizers are not alone in starting Summit preparations. In 2011 Summit preparations Program Task-force took the lead in overall planning. Reason for that was simple. Community manager and two other initial promoters of the Summit worked in same company (Hermia) and were located in same city. Two of these key persons were in the Program Task-force as well and the third knew the facility providers in Tampere extremely well and was experienced event organizer. This triangle formed the ‘high council’ to make last decisions after discussing issues with others. In other words, even if Event Team would start the preparations, some kind of ‘general management’ team -even if it is distributed in several teams – will most likely be established and some outsiders can be included if necessary.

Additional activities

Meetup participants often continue the night after meetups. These events or activities are not really tasks of organizer(s), since post-meetup gatherings for example in nearby bar often occur without interfering. At least in HMN and TMN people go to nearby restaurants after the meetups for a few beers. In Tampere, sometimes nearly half of the meetup participants (normally around 40-50) attend the post-meetup gatherings. The significance of post-meetup meetings is mostly related to networking and continuing discussions which started at meetup.

Another possible task for meetup organizers is to act as contact person between other local communities and MNFI/Local MeeGo Network. An example of this could happen in Tampere. In Tampere we hold our meetups at Demola. Demola is now building some kind of developer lounge, which is supposed to be a place where Demola visitors and student can get their hands on different devices.  Those devices will also include MeeGo OS.  The lounge is as far as I know planned to be used also as demo site, where applications and other presentations could be held. I would like to see presence of TMN and MNFI in that lounge. By presence I don’t refer to maintaining the space, but more like a chance to attract more people to MeeGo activities and spread knowledge about MeeGo. This would be important since visitors of Demola often include key members of local companies, students and City officials. Having meetups in fixed location would enable deeper cooperation with the facility owners.

As it can be seen, meetup organizers act pretty independently and that’s how we like to keep it.

Marketing team

This team was discussed earlier and the role of team is changing already. In our February community meeting, responsibilities between marketing team were altered. This was due to too high overlapping in tasks and responsibilities with the Communication & Tech team.  Now this team is responsible for: marketing material such as posters and leaflets, media policy, website content policy, social media accounts, press releases and other press related issues. In addition to that, Marketing team lead acts as community managers right hand or side kick. Now the task and responsibility division between the above teams is more clear since C&T is now responsible for: MNFI portal development, Summit venue IT infrastructure/connections, Live streaming of presentations during the summit, video interviews (speakers etc.), App for summit program (summit program related, not Intel), Summit registration tech, IRC channel(s) (ops) and Mailing lists (freelists.org, meegonetwork.fi).

Development team

Members of this team are still true hack3rs! Just the name is different. One of the new responsibilities of this team is to manage our ‘organization’ and members of it in AppUp Developer Program (Intel). This team will continue (hopefully) in developing tools for us. In other words, they stay with the code and hardware hacking. I guess this team is how most people (the great public) see Open Source communities, bunch of coders.

Task-forces

Of course all the things do not fit into the above teams or if one team is stuffed with loads of tasks and members it will become hard to manage. Remember that optimal team size is 7-12. People can not always participate in team work, they will be absent sometimes even for weeks. Then if team size is less than 7,  the broadness of skill is not enough and absent members make ‘holes’. Again, if there are more 12 members, it will make management and coordination harder (but not impossible).

Therefore, it is necessary to set up task-forces, which were discussed in the beginning. In the previously introduced structure of MNFI Event Team and Marketing Team has some gray puzzle pieces. They represent the task-forces. These little units can overlap between teams more than normal teams, but they will live for relatively short time and for specific purposes.

Closure

So this is my view how MNFI could be restructured. The moment for another redistribution of tasks is not now. Suitable time could be after MeeGo Summit FI, after which some kind of restructuring is necessary anyway. Of course all the above is still rather vague and by no means perfect. Also the role of portal is still unknown, since building of it has just began and no-one really knows what it will be. Hopefully it will make some tasks easier for all and unites information flows. As a recap, below is current and new (possible) MNFI structures.

Current

New

Any thoughts? Just add comment below. Feedback is always welcome.

Most of people working with or around MeeGo should be aware of the decisions Nokia announced Friday 11th Feb 2011. In brief, Nokia announced that the new strategy includes “a broad strategic partnership with Microsoft to build a new global mobile ecosystem; Windows Phone would serve as Nokia’s primary smartphone platform.” According to Nokia (Elop) this does not however exclude participation in MeeGo development, “MeeGo will place increased emphasis on longer-term market exploration of next-generation devices, platforms and user experiences. Nokia still plans to ship a MeeGo-related product later this year [2011]“. After a week there is no detailed information what this means for Nokia people working with MeeGo. At least some have continued with MeeGo, some not. In my eyes, this item is just a bump on the MeeGo road, a bump which was needed. Why?

Bumps are needed.

Personally I needed this bump, but perhaps the global community needed it too. It has been rather hectic during the last few months. It gave me time to evaluate our efforts and take a breath. It also forced me and perhaps others too to reconsider the role of MeeGo community. By community I refer to all who participate in MeeGo development including paid staff and volunteers. Bumps are rarely pleasant, but often needed to get new angle to issues at hand. The amount of uncertainty what is going to happen to a lof of developers and MeeGo, was probably the biggest issue to raise unpleasant feelings. For the community, bumps like this one, are tests to processes and ability to react to different changes that occur without any warnings. Healthy community is ready for such bumps and has created tools and methods to overcome problems and challenges to continue forward. The worst thing community can do in such situations, is to sit and wait. Ok, even worse is to look back and fall into self pity. Wait for what? Salvation from outside? It might come or not.  Silent revolution is on! Redistribution of power is on! There will be no big guns blasting and people on the streets. The longer community is without clear direction, the more people get frustrated and start to flee,  search other projects and areas to contribute. Community needs to react, not wait, and it has. During this week, two things happened: Community responded and Intel took the lead.

Intel took the lead…

Intel has been the other partner in developing MeeGo with Nokia. Now that Nokia decided to go with M$, Intel took the pole position. Nokia has not been able to tell community what it is going to do with MeeGo. They say things like participation with “significant amount” of resources. That’s good, but how long is the community supposed to wait for something concrete? This shift in lead was visible in Intel’s efforts during this week. Intel has thrown all-in.

Intel has mobilized own activities and dragged several others to engage too. The moment for shifting to bigger gear was right and the place for it was Mobile World Congress 2011 in Barcelona. In MWC and around the world several news, announcements and technology demos have been related to MeeGo. Here’s a few:

1. Intel began to push AppUp developer program more aggressively (competitions and free of charge membership in developer program). MeeGo Network Finland is there too as ‘meego-fi’ organization with nearly 20 members.
2. Intel’s MeeGo AppLab at MWC. More Intel MWC
3. MeeGo TV (preview) was introduced (youtube)
4. Splashtop Releases MeeGo-Based Splashtop OS for OEMs
5. Intel introduced their view on MeeGo tablet UX (Odd is that sources are not contributed to community, hopefully changes soon)
6. Fujitsu introduces its First MeeGo™-Based Netbook in Asia Pacific
7. MeeGo Tablet UX on WeTab / ExoPC (youtube)
8. NPad MeeGo-powered tablet to combat the iPad in China this fall

In MeeGo Network Finland

In our community (MNFI), scale of feelings has been broad. In general people have been quite peaceful. Under the surface some of the hardcore FOSS people have perhaps felt somewhat disappointed. At least I did and still do. To me this bump was also a kick in the teeth, giving the finger to FOSS. This kick did not drop me to floor. Instead it raised fighting spirit. Some others have felt the same. People see future in Open Source, not in grasping to closed source solutions. I must admit that I’m biased, since I love Open Source and hacker culture. Both of which hardly ever include loving feelings towards closed source solutions favoring corporations. The image on the left represents just my own ideology, not everyone in our community.

Bumps and MeeGo Summit FI

Summit was on hold for a week or so. We were waiting for the dust to settle and give some time for the sponsors to regroup their forces. This was most unpleasant time for me. Now situation looks more bright. At this moment we proceed as planned. I did push the people responsible for the sponsoring to do something, but they told me to wait. And so I did :) A few speakers might be cancelling thei participation, but that can be overcome rather easily. We haven’t asked the speakers yet whether they are coming or not. Instead, some of them have approached me (such as Kate Alhola, Carsten Munk and Jan Krebber) and informed that they will come. Biggest loss is that Thiago Macieira cancelled his participation, but that was due to personal reasons and had nothing to do with the events described above. Intel and some other sponsors have already confirmed to stay with us. Intel has confirmed to sponsor Meegathon competetion. In addition to some hardware prizes Intel “is thinking about a special prize for the Meegathon – and will come back to that later”. It looks that if big setbacks do not occur, we will have the summit as planned. Interest towards the summit is still huge. People are signing to queue for cancellation seats. In brief, regarding the summit, nothing new in the Western Front.

Obviously people have roles in communities. MNFI is not an exception, but structure and interactions of the community are still rough. This is understandable because community has been around for about 4-5 months. Yet some roles can be identified already. Roles described below are not result of any clear (systematic) scientific method, they are based on my experiences and observations.

Community layers

National community, such as MNFI, can be seen to include at least three somewhat independent layers: 1) local MeeGo networks, 2) teams and 3) national network. Clearly there can be more layers, but this post attempts to give only one view. In our case LMNs are independent from the national level, MNFI. Local MeeGo Networks organize meetups in the real world. The approach may vary, but most aim to organize meetup once a month. Organizing meetups is discussed in some details. On the national level, several teams can be formed. Each team has a team lead which should direct and coordinate team efforts and report to larger community about results and problems. Teams are the building blocks of our national community. Teams unite people coming from different LMNs. Labelling regionally LMNs and teams uniting body as national community is a bit problematic, since some members can be from abroad. The figure below offers one view to community roles and connections between the layers. The figure is not intended to describe every possible variation of membership/role modes. It only presents some role/membership forms and needs more work to become more valid, accurate and useful.

Roles

Roles are something that can not be avoided. Every member of group or larger community has a role or even multiple roles. It is natural for humans to seek their ‘position’ in a group. Roles that people have are based on group activity. People might have several roles at the same time depending of the nature of their level of networkedness. Roles are not sticky. Instead roles come and go when people join or leave LMNs, teams or other group formations. The below described roles and descriptions of them, are based on my observations and therefore have no scientific background.

In the figure red squares are local MeeGo networks, green circles are local members, yellow circle represents foreign members and blue triangles are national level (MNFI) teams. Now let’s take a look at some roles.

Some members are not member of any LMN. It is not mandatory to be member of LMN to participate otherwise. Instead they might be part of national level team(M3) or even multiple teams(M1). Those members who are involved in several teams and/or LMNs, are keyplayers to community since they pass information from one team to another. This is something that Bacon has emphasized in his book (The Art Of Community). I have placed the current ‘end-users’ to this group (’participants and followers’). In future they might form a separate grouping, if MeeGo is a success. Their role is still vague and therefore left out for now. Some members prefer to stay active only in local meetups (M2). As discussed before, some members of the teams and LMNs can be from abroad(M4).

Meetup participants and followers

Some MNFI members are actively involved or at least members in several LMNs (member M1 in the figure). I for example am member of Tampere, Helsinki and Oulu MeeGo Network. Dispite of this multimembership, I am active in one local network.

Developers

Some of the members are clearly hackers/developers. They have no interest (or just minimal) in community management or other similar tasks. They wish to code, explore and be innovative. This role or group mode is what normally constitutes the core of FOSS communities, at least in development point of view. Developers come in different flavors. Some of them are n00bs and some are old skool. Naturally there are developers who are somewhere in between the two extremes. Another feature of developers is that some of them are paid to do development and some are pure freetime developers. This is common in current FOSS development projects and MeeGo is no exception.

Supporters

Normal supporters are companies which sponsor meetups. They can offer facilities, beverages, food and even post-meetup activities. Supporters include also ‘angels’, oldtimers in FOSS development who support, help and encourage new communities. They do not have a clear position or role in community, and are present mostly in the background. Their input is highly valued, since they have a lot of knowledge (partly tacit) about the larger commmunity and practices in it, in this case global MeeGo community. Local media can be seen as supporter if it can be mobilized to promote MeeGo activities in your area.

Community Builders

This role includes community managers, meetup organizers and team leads. Community manager could be seen as a facilitator, which tries to enhance community activities and inspire members, suggest direction for the community and if necessary solve disputes and fights. Community manager can also act as advocate and visit schools, summits and other events to promote own community. Community manager can also be the bridge between own community and global community level decisionmakers, a bit like a liaison offficer. On top of all the above, community manager should also act as a buffer between community and other organizations such as companies. This might be necessary to keep possible company related power struggles outside the community. The above might look a lot for one person. This is where community teams and team leads come in.

Teams can be formally constituted or let them be born by themselves. Teams should have a lead, which coordinates team efforts and communication. Team leads should be trusted members who are actively involved in community. Selecting team lead can be simple. One option is to select leads by merits. In other words apply some form of meritocracy. Since the leads are supposed to be trusted, it might be wise to do the nomination (or at least introduction of new leads) in community meetings.

The third form of community builders are meetup organizers. Their role is important especially to LMNs, since it’s their responsibily to organize meetups in real world. They should be active and try to inspire members to bring up new topics and ideas for presentations and activities in meetups. They do not dictate what topics are taken to meetup agenda, they merely suggest and coordinate so that every meetup would be somewhat coherent. Of course, every LMN can have different methods to define agendas for meetups. Some might even not to have agenda. In our case (TMN) we have had agenda every time. Some have raised the opportunity not to have agenda. I might go with that, if the community would be more mature. At the moment, having no agenda at all, would most likely result to meetup without any presentations. Furthermore, I have a gutt feeling that participants want to know what is expected to be seen or heard when deciding whether to attend or not. Therefore, I would suggest that some kind of agenda is always formed in cooperation and through discussions, and presented somewhere public.

Some LMNs organize meetups in different locations. This might work in some occasions. Some hold meetups in local restaurants, bars and other similar facilities. Personally, I don’t need a LMN to get a few drinks in a bar and discuss MeeGo. I can do that without LMN. Some LMNs organize meetups in sponsored facilities and rotate from one place to another. Again, this might work too. This kind of model forces LMN to follow what the sponsors say and offer. Instead of that, I would turn the setting upside down. Let the sponsors follow you. We have done this in TMN. We have a permanent location for our meetups. The place never changes and sponsors follow us there. Of course this is possible only because New Factory has given us the possibility to use their facilities. This kind of mode has some benefits. Firstly, people always know where to go and become familiar with the settings very quickly. Secondly, we don’t need a new sponsor for every meetup to gain access to some facilities. Thirdly, sponsors can concentrate their input to food, drinks and other fun kind of support such as arranging sauna. Lastly, having a set place enables always ready tools, such as WiFi, screens for presentations, for meetups. Having a permanent place might even enable other kind of cooperation modes and networks. For example, in Tampere we have began to build cooperative network with Nokia and New Factory to set up a permanent ‘MeeGo Café’, where people could try MeeGo devices (5 days/week) and even loan devices for development purposes. The café would have other activities too, but they need to be defined later.

In one of the previous blog entries I advised to have focus on your Summit or in any activity your community aspires. I took this issue under work once again and checked out what other MeeGo conferences, summits and cons will be available for the Finnish ameegos in our region. From the event listing on meego.com I found several conferences and summits in Europe.

What I discovered, was that three approaches to MeeGo ecosystem are present: academic, developer and business (see figure on the left side). The situation looks rather promising, since every significant event in our region seems to have different approach to MeeGo.

It is great that several communities and organizations are organizing MeeGo events during this (2011) spring and none of those events overlap. Downside is that having several events in such a small region, will ‘eat’ participants from every event. This is very unfortunate and hopefully this will be different in the future. Let’s take a closer look at what these three events have to offer.

Academic - Petrozavodks (Russia)

I have to admit that this event/conference was a surprise to me.  The FRUCT Program has taken the role to hold academic MeeGo conference in our region. This is natural choice for them since the FRUCT program conferences are normally attended by the representatives of over 15 FRUCT universities from Russia, Finland, and Denmark, and industrial experts from Nokia, Nokia Siemens Networks, and Symbian Foundation(I thought this is sort of dying breed). The foundation of this program is in the co-operation between Finnish and Russian universities which operate/do research in telecommunications.

Conference details:

Business - Oulu

Oulu is organizing a business oriented local mid-summer summit in northern Finland. The organizers consists mostly of local companies, but city of Oulu also has strong presence. Even though  the summit is business oriented, it includes tracks which might interest someone else than just the ’suits’.

Summit details:

• Date:  30 Apr 2011 - 1 June 2011
• Location:  Oulu, Finland
• Web Site: http://www.meegosummitoulu.com/

The reasons why Oulu has chosen to focus on business may have background in the activities and nature of the local Oulu MeeGo Network. It is populated (as far as I know) more or less with business people (~30 members). They have not managed or wanted to engage local developers into the network, at least not yet. Futhermore, organizers of the summit and Oulu MeeGo Network have strong interest to bring city of Oulu to the front. This is somewhat different compared to for example Helsinki and Tampere MeeGo Networks (see below), where the MeeGo community is more in the focus.

Developers & hackers - Tampere

MeeGo Network Finland (MNFI) is our national MeeGo community, which has been formed last year and it has over 200 members. MNFI is mostly developer and hacker community at the moment, but will include end-users in the future. Active local member networks include Helsinki and Tampere. MNFI organizes in co-operation with several local partners (such as COSS and Hermia) the first of a kind full-blown developer summit, which carries the official name MeeGo Summit FI.  MeeGo Summit FI is community-driven event, which means that our local network members (developers) have defined what the summit will include and the same persons will handle most of the tasks related to the summit. More information about the MNFI community.

This is ‘teh’ event for all MeeGo developers in Europe. Program includes 3-4 keynote speakers, three tracks, evening party, Meegathon competition, BOFs, workshops and AR drone fun! Speakers include several top MeeGo developers and community members such as:

• Carsten Munk (keynote)
• Valtteri Halla (keynote)
• Thiago Macieira (keynote)
• David Greaves
• Dave Neary
• Ville Ilvonen
• Kate Alhola
• Jan Krebber
• Justin Noel
• Adrien Bustany & Ivan Frade

MeeGo Summit FI is one of the top developer-focused MeeGo events in the world. By the way, this event is free unlike the two above. Furthermore, the Finnish open source community will hold annual Finhack (Saturday) in the same premises.

Summit details:

• Date:  15-16 Apr 2011
• Location:  Tampere, Finland
• Web Site: http://summit.meegonetwork.fi/ (will be updated to include details 1st Feb 2011)
• MeeGo wiki: MeeGo Summit FI

Future summits

In the future, events in our region should (IMO) be combined so that we would have just one national Summit instead of having both national (MeeGo Summit FI) and other summits. Furthermore, if and when MeeGo activities in Sweden and in other Nordic countries begin, we might even have a Nordic MeeGo Summit every second year.

An ocean of ideas

In the early stages when we were thinking about the MeeGo Summit FI content, an idea of hackathon kind of competition came up. Obviously some of us checked out what kind of settings, ideas, rules etc others have generated. Multiple ideas emerged and were tossed around in the community. The whole content and structure of the Meegathon started pretty much similar as competitions around the world. It looked nice and clear with two separate categories: hardware and software. A lot of members wanted to see onsite coding as one of the main features of the competition. That would have probably worked and might have had some success. Nevertheless, it was a bit lame and sounded a bit old and worn. Despite of that, initial competition model was drafted and forgotten for a moment.

It would have been safe to arrange a similar competition compared to dozens of hackathon type competitions around the world. We wanted (some of us) to do something different. We took a risk. Time will tell if the risk was worth it.

Flying gadgets

The idea to include something relatively new as part of the competition came to my mind as I was visiting Helsinki MeeGo Network meetup in December 2010. I was there to give a presentation about the MeeGo Summit FI 2011 and to get ameegos in Helsinki as part of the organizing teams. I presented the ideas and after that there was some mingling and talks between people. Lucky for me, I ended up discussing with Kate Alhola, who introduced me and others to flying gadgets (better know as Quadricopters). I got back to my tasks and forgot the flying gadgets for a month or so. For some reason I just remembered it and started to think it as part of the competition. The more I read about Kate’s work with the Quadricopters and watched videos from youtube, the more I was convinced that this might work.

At this point the composition of the team which was drafting the competition changed. Until that moment, there had been just a few people involved. I expanded the team by involving Kate into the process. This seemed natural. She had the most information about AR.drones and she had already done pioneer work on it. Simultaneously with Kate, two members who had already participated in other competitions were included to the team.  Based on their experiences we dropped the requirement of pure onsite coding (it is still included as valued aspect but not as requirement). Instead we started to approach the competition model from community perspective. Kate kind of pushed us to go there.

The reasoning for the selected structure and rules

AR.drones are somewhat new and cool gadgets. The device was introduced at the Las Vegas International Consumer Electronics Show (CES) in 2010. Because of that, Open Source development in libraries used for creating AR apps is still quite small. Also the development regarding the tools for lib and app development is mostly absent. Instead of forcing competition participants to create something hasty in 24 hours time, we wanted to start a long run development cycle or process. One of the ideas or purposes of Meegathon is to get more people involved in AR.drone lib development. This might create a new community around AR.drone related libs. This is why we have chosen to reveal (30th Jan 2011) the reference scenario months before the Summit.  People need time to produce good quality code and get familiar with the scenario and tools.

We didn’t however want to rule out that people can participate with something else than the given scenario. We intentionally left the back door open. You can participate into the competition with something totally different. You are allowed to choose your own agenda for your project. Furthermore, hardware inventions and unusual use-cases are welcome.

Releasing the scenario early is intended to get more stable code and more ‘wow’ effects. What about after this competition? Most hackathon competitions start and end at the same event. We would like to see other MeeGo events (organized by Nokia, Intel and others) to include similar setting in their future competitions. This could possibly speed up the development and teams could set goals for the development. Furthermore, drones combined with MeeGo devices could be one of the coolest technology demos to ’sell’ MeeGo and Qt around the world.

Part of other activities

Obviously it is fun to play with toys, even when you’re adult. Therefore we have decided to get some quadricopters for the Summit participants to play with. The activities does not have to be complex, just some initial settings for the people to get started. A few drones, lots of space and freedom to explore and try. Having quadricopters without the connection to Meegathon would have been sort of…out of context.

Introduced in TMN meetup

In April 2011 we had Local MeeGo Network meetup in Tampere, where one of the top developers (MAR.drone), Kate Alhola, presented what has been done already. The session was recorded (by several participants) and will be used in Meegathon marketing. Tampere has been lucky regarding the drones, since Protomo (part of New Factory which is the base for Tampere MeeGo Network) was convinced to order one Quadricopter for development purposes. Convincing Protomo lead was not hard at all. All that was needed was to look thrilled like a little kid and ask. People in Protomo like hackers and people outside our community were also interested about it. Some other MNFI members have also ordered their own quadricopter after the TMN meetup and buzz it has generated. Below two video recordings from TMN meetup.

In brief we found out that we can combine the Meegathon, help to boost AR lib development and have fun with the Quadricopter! Did we have this idea in the beginning? No, it just happened :) All it took was to include different kind of people into the process.

Meegathon

Meegathon competition will be opened for teams 31th January 2011. Team size can be 1-3 persons. More information such as detailed competition scenario, rules and team registration will be at http://summit.meegonetwork.fi by the end of this month.

More information about drone:

1. Review
2. Parrot Discussion Forum
3. Drone & MeeGo (Kate Alhola)
4. Technical details
5. Maemo Garage( MAR-drone)

Inspiration:

1. Constructing with drones
2. ‘Surveillance’

I’ve been fascinated by hackers and hacker culture all my life. About 2 years ago I stumbled upon Hackerspaces while I was looking for new forms of hacker culture. It was love at first sight. I found out that there isn’t any hackerspaces in Finland. So, I started to build one - Mode 5w. Things didn’t get started very well and the building of that little community is still on. However, we just found a promising space which might be suitable for us. Anyway, my fascination was so deep, that I did some research about Hackerspaces during 2009-2010. You can read more about that in here.

Things lead to another and I found my self thinking: “Why does Local MeeGo Network (LMN) type of activity sound so familiar to me?” The obvious reason is the huge similarity between hackerspaces and LMNs. Of course there are bunch of differences too, but let’s take a look at both, the similarities and what LMNs could learn from hackerspaces. One might wonder why LMNs should take a look at what hackerspaces have done. Hackerspaces have been around for decades already. They have faced a lot of difficulties and based on their experiences have created several good ‘rules’ and guidelines.

Starting a community

Starting a community in MeeGo context refers to creating of new Local MeeGoNetwork into some city or regional area. Comparing the guidelines about how to start a new community reveals that both apply the Rule of Critical Mass. In Meego community 5 aMeeGos are required to get ‘candidate’ status. When the candidate LMN arranges the first meetup, they are granted ‘full’ status (can remove the ‘candidate’ suffix in their name). In hackerspace context the (normative) rule is called 2+2. Firstly, you need a partner to get the initial idea kicked off. That makes two of you. Then you need two more people in order to get real work done. Nothing should be started before you have at least four people, but aim at 10. In hackerspace world status gained after critical mass is called ‘building’ (equivalent of candidate in MeeGo world). In hackerspaces context functional hackerspace is in ‘active’ status. No one controls directly who uses and what status.

Members

Hackerspace members are mostly Open Source enthusiasts, use FOSS tools or at least think positively about Open Source. Furthermore, most of them seem to follow Hacker Ethic and the values it includes [survey study results]. What about MeeGo Networks? After organizing Tampere MeeGo Network meetups for 4 months, my gutt-feeling is that (no surprise) most members have warm feelings towards FOSS and hacker culture. This has been the case at least in TMN, where the first people coming to the meetups were developers, not the ’suits’. The most significant difference is that, in hackerspaces members have more diverse interests than in MeeGo Networks. In MeeGo Networks, information where someone works and what’s his/her job, seems to have more importance than in hackerspaces. In other words, MeeGo Networks are not pure freetime communities, business is lurking in the background all the time. Hackerspaces do not want to be attached to corporations, they want to remain as free as possible. In other words, similar sponsoring model (member corporations sponsor for example food & drinks) which some MeeGo Networks uses, is not acceptable. The LMN sponsoring model is good, but contains the possibility of power struggles between sponsoring corporations. Besides the bigger sponsors have significant advantage when compared to smaller corporations. So how does hackerspaces fund their space rent and activities? They use monthly member fees. In brief, hackerspaces represent pure member-run and funded communities, which is not the case on LMNs. They are more like business-funded yet member-run communities. The role of members in LMNs and hackerspaces is different.

Physical world extensions

Both require physical world activities such as meetups. Hackerspaces normally start with meetups which can be compared to MeeGo meetups. This is where/when LMNs normally stop or satisfy. They have meetups once a month perhaps. The content of sessions or meetups vary from simple presentations to live coding and demonstrations. Then if the local community wants, they create tools and methods to meet in virtual world. This is great. People meet in meetups and get to know each other. Then the communication and collaboration in virtual world is easier. Now the LMN is granted active status.

Hackerspaces take the community aspect a bit further. They do all the same stuff as LMNs do. But to become a ‘full’ or active hackerspace, it has to have a physical space. A space which functions as the center for the community. The space is the core of community. Everything is build around the physical space. The space normally includes some kind of toolshop where members can do HW related development. It might include classrooms for teaching, a living room to hang out with other hackers, kitchen and what ever members want to have. In brief, hackerspace can be seen as a ‘third space’. First space is home or family. Second space is work. Hackerspace is something that exists in separate - third - space.

Motivation

It’s quite impossible to define what are the motivations to participate in LMN activities and become a member. Some well educated guesses can be done but there has not been any studies about the subject. My hypothesis is that this is where the biggest differences can be found. As I mentioned earlier, I did a small survey (n = 201) about hackerspaces and members of hackerspaces in summer 2010. In hackerspaces the most important factors to participate are:

Altruism, community commitment, meeting other hackers in real world and having fun

Motivation for taking part in hackerspace.

If the same survey would be done among LMN members, some differences would probably be found. A bit similar survey study (attempt) was conducted in MeeGo community before the end of 2010 (see the invitation). Survey received a lot of critics (some justified some perhaps not) and only 38 ameegos took part. In my opinion, this reflects also the status of MeeGo community. It is still young and not yet so willing or mature to want outside views or information about it self.

The MeeGo community is more rigid and hierarchical than hackerspaces community. This became visible in the discussion related to how the survey was not approved by the community managers before exposure to the community. Although some members objected the need to get approval from somewhere (MeeGo council which does not even exist) to do a survey and pointed out that this is Open Source community after all. Some compared academic surveys to actions which are aimed at getting personal benefit, which is a bit odd. Survey was obviously considered as spam by some members, which should not be posted to the mailing lists. The bad language and somewhat poorly structured questions (member opinions) were big reasons for not taking part in the survey. Someone even claimed that the “[original invitation to participate in the survey] is an invitation to a non-MeeGo survey, it’s an advertisement.”  Again this is bit odd viewpoint, but duly noted.

One reason for objection was perhaps that some members of the community saw the researcher as an outsider. It is true, that I haven’t contributed a single line of Qt code to the community, but I have been active in organizing local meetups in Tampere and started to build a national MeeGo community. Perhaps some ameegos should rethink the attitude towards non-coding members of the community. Some members seem to follow rigidly the FOSS onion model described below.

One critic towards the survey was about the benefit of academic surveys. According to one ameego academic surveys come and go “without realistically contributing back to that particular community.” The claim might have some truth, but this kind of attitude and prejudice towards scientific surveys does not really encourage scientists to approach MeeGo community or do research about them. Is that really beneficial for the MeeGo community? Nevertheless, if someone will do a survey among the ameegos in the future, the above critics and viewpoints should be considered first. Good luck! :) Needless to say that none of the above was relevant in the hackerspace community survey process.

Conclusions and suggestions

When comparing both communities, it might not be too bold to say that LMN is something between a pure open source community (such as Ubuntu LoCos) and hackerspaces. LMNs are hybrids, which take the benefits of both ‘extremes’. The traditional onion model used in FOSS research does not seem to describe LMNs very accurately. Onion model is software development oriented model. LMN could be described better if the approach would be community oriented. Why? Because if you look at the onion model below,

Source: http://firstmonday.org/htbin/cgiwrap/bin/ojs/index.php/fm/article/view/1623/1538

you can see that a lot of roles are missing. There is no community manager or where to put all people exited about real world events? Where to put HW development oriented aMeeGos? Perhaps the roles could be described similarly as what has been found from hackerspaces (’Community roles‘)?

It might not be such a bad idea to get a permanent location for the meetups. It would probably stabilize the LMN, since all meetups would be held in one place. An example of this is Tampere MeeGo Network. All meetups are held at New Factory. People know where to come and there is no need to ‘hunt’ a new place for each meetup. I would take this even further.

Now, this is where ‘Meegolandia’ steps in again. Meegolandia would be a ‘MeeGo Centre‘, a kind of MeeGo hacking ‘corner’ or meeting place where the presence of Qt could be strong. It could be a bit like a hackerspace. We could have great MeeGo release parties twice a year and invite new people there. It could include small or bigger scale teaching. How? Just get local universities and universities of applied science as partners into your LMN. What about business? Member partners could demonstrate latest inventions and applications. If we could regularly get both end-users and developers in the same ‘room’ ones a month, it certainly would not hurt the development. Imagine the looks on the face of the users when they can really meet the developers in flesh.

Open Source communities or projects are known to be sort of slow like a diesel train, but once it gets on the move it’s hard to stop quickly. Decision making in F/OSS is sometimes slow, it takes more than one online meeting to have decisions about issues that might in some other context be made in one meeting. Don’t take me wrong, sometimes slow decision making is good. It can bring some thought behind the decisions. Nevertheless, having a fluent, efficient and above all clear decision making process is important. Members of the community need to know how they can influence and what is expected from them.

Different kind of solutions have been tested in different communities and projects. Bacon stresses the importance of clear and simple processes throughout the community. In this blog entry, I decided to concentrate on two aspects how to make our workflow and decision making a bit more fluent. The selected aspects are: team workflow and meetings. More precisely, it’s a question of how to combine these two so that neither of them is neglected or in contradiction. Contradiction would mean undesirable obstacles which we want to avoid. Team work normally contains different amount of tasks. Efficient management of the tasks is one element on the way to ensure fluent workflow. Therefore, a simple solution for bridging meetings and task management is also discussed below.

Before meetings

It might seem obvious to most of us, that meetings are places where decisions are made. They are not the correct place for in-depth or wide discussion. If such discussion is needed in the meeting, something has gone wrong before the meeting. In most cases, there can be two reasons. Firstly, participants don’t read the information given to them in the meeting agenda. Secondly, person responsible for the item discussed, has not finished the task and/or given the necessary information for others to read before the meeting. Both of the above can always be resulted by mistakes. We are human after all. Of course there are exceptions and rather long discussions can occur.

It is important that teams work between the meetings and document what has been done. The documenting does not however have to be 200 pages manual. Simple bullet-points would be enough. And if possible, it should include proposition for further actions (to be approved, needs more work or questions that could not be answered). The documenting should be done incrementally if possible and be finished no later than 24 hours before the meeting.

Participants of the meetings should respect the efforts of others and read what they have done before entering meetings and start asking questions. In our community, all members have the right to raise an issue by adding it to the agenda 24 hours before the meeting. If you add an item to the agenda, it is your responsibility to add enough background information about it for others to read before the meeting.

Meeting chair should prepare each meeting in advance. Jumping into a meeting without any preparations can possibly work after significant amount of experience, but is not necessarily the best way. If this is your first meeting as a chair, seek advice from the previous chairs and get familiar with the tools (meeting bot commands and procedures). You probably know already most of the stuff, since this shouldn’t be your first meeting. It might not be such a bad idea to dry-run the meeting once if you are acting as chair for the first time. No matter how well you prepare the meeting, something unexpected will occur and you just have to improvise. You will probably make some cock-ups. Don’t let that stop you, we all make mistakes. Other participants most likely know that this is your first time as a chair. They will be merciful…once. Having a co-chair might not be such a bad idea. If there are two chairs:

1. one can concentrate on the discussions while
2. the other can do the notes (use bot commands to set the topic, add actions, infos and other items to the meeting minutes).

During meetings

Online meetings might look ‘messy’ for the beginners. Comments come and go, some stay on the topic and some don’t, people ask questions and no-one seems to answer them. The pace should be slow, so that people have time to express themselves. Obviously the amount of topics (in agenda) can seldom be big. In our community meetings are 1 hour long, not any longer. If we run out of time, remaining items in the current agenda will be transferred to the next meeting agenda. Why only 1 hour? Remember, meetings are not the place to have lengthy discussions, they are places for decisions. Discussions take place at mailing lists and IRC -channels. It is though difficult to draw line between needed amount of discussions and too long discussions. Here’s a few points to keep in mind when participating online meeting:

• Try to express yourself clearly and in short sentences. Avoid long ‘copy-paste’ texts.
• Let the presenter finish before asking questions. The chair normally asks for questions at some point.
• Discuss questions one by one, not in parallel.
• Don’t return to previous items, it only confuses the discussion.

During the meetings, tasks and actions to pursue some goals are normally identified. The chair should try to identify suitable members to take care of the actions needed. Name the person for the task. Intention is not to find someone to blame or put extra pressure on anyone, but to create responsibility. Naming a person to task often generates responsibility. Furthermore, tasks with assigned persons normally tend to be handled sooner. If a task is an ‘orphan’, without assigned person, the task more likely will be neglected, forgotten or avoided. Second best solution is to assign a task to some role such as Team lead. This works as well, since normally Team leads are highly responsible persons.

After the meetings

After the meeting - if all goes well - there’s some tasks assigned to different people. That’s not enough though. Normally people do the tasks they are assigned to, but they don’t seem to understand that others need to know when the task is done and what has been done. Especially Team leads and community managers who coordinate efforts need that information. In other words, following and documenting the results is another important thing. Once assigned people have done the task (or failed for some reason), they should add steps and what has been achieved in some public place. Below is  one example how this works.

1. Task has been assigned you or me in the meeting (or internally in team workflow). We trust that the assigned person can handle the task and value his/her input. In other words, respect that someone contributes time, skills an efforts. Task example, just to clarify this process. I was assigned to a task: “I should find out can Linux Foundation sponsor three speakers to our Summit”. Now the assigned person should think, who could help me in this task and find such person.
2. Start doing it in collaboration with necessary people. Get in touch with others. It might not be such a bad idea to find a pair to do the job. Doing stuff together, is more fun than alone. If you get stuck with something, seek advice from team lead, other team members and the whole community. Regarding the example task I would seek out someone with great writing and communicating skills. Together we could start to write an email for the Linux Foundation
3. Use asynch/synch tools
   • Use mailing list if the issue needs to be discussed in community level or to ask advice and get opinions
   • Use IRC for (quasi) synchronous discussions.
   • Use Etherpad for text collaboration. Again regarding the example task, we would choose etherpad to work with the email.
4. Evaluate the results. Regarding the example: we both would re-read the email with thought, possibly ask a native English speaking person to proof read it. If the email is adequate, we would then send the email and wait for answer.
   • Document what you have done. Use a tool that others can access too and possibly even contribute in it. Example: etherpad, wiki page or pastebin. Use the tools, you are comfortable with.  Others need to see what you do. That way they can contribute into it and offer suggestions. In the example task we would let others see our etherpad document while writing the email.  Not exactly the best example, but you get the point.
5. Once the task is done, let everyone know that the task is done. Currently we use wiki page to list the community meetings and agendas for them. You should add a brief description about the results under the meeting agenda. Also you can add a link to your document so that others can read what you have done. See example: agendas. Of course you can mention the results in IRC channel too. Regarding the example task, I would add a bullet point below the agenda: “Email to LF was sent 8th Jan. LF agreed to sponsor our Summit by paying the flights (but not hotels) for three speakers.”
6. In the next meeting people have a chance to give feedback about what you have done. Also, you can bring up issues related to the task if needed. In the optimal situation, there is no need to return to the task, it’s just done and results are approved. If it is still undone (for whatever reason that might be), then return to step 1.

Bridging IRC meetings and task lists.

Currently our workflow does not include automated task lists or bridge online meetings and any tasks. As it was mentioned before, we use meeting bot, which generates meeting minutes. When we make the transition to our portal in the spring, we might want to create a solution which makes the bridging. I’m sure that Drupal has modules/plugins which we can use. Here’s a scenario how it might work.

1. We use meeting bot as we do now to list actions. The bot is capable to assign a task/action to a person (if used correctly). The bot generates the meeting minutes, which can be accessed.
2. Then the portal has a (automated daemon type) function to pick the actions from the meeting minutes and and add those tasks to general tasklist. The tasklist -view in the portal would include all the tasks assigned to any member of the community. Of course the task listed in the portal could have different statuses to indicate whether it is done or not. These tasks lists would also be visible to all community members.
3. In the portal everyone  has a profile and personal ‘page’. It could include a ‘My tasks’ -view, which would include all the tasks assigned to me. That helps the user to see his/her current tasks without searching or browsing the general tasklist -view.
4. People can add notes and links to (possibly wiki kind of content creating) the tasks.
5. Unassigned tasks would be listed and assigned later by the team leads or community manager. Of course any member of the community can claim such a task (assign self).

Obviously the tasks could be grouped and/or categorized for example by teams. Furthermore this could be part of community metrics and analysis (tool for Community Manager). Metrics could include the amount of tasks assigned and finished, time the tasks took to finish, figures to identify key members (those who do most of the stuff = give credit and more responsibility), amount of unfinished/unassigned tasks, etc. The system could also include task classifications for importance, but that’s not always necessary.

Creating such a simple system/bridging would ease and possibly simplify the workflow significantly. This kind of task management would probably be enough for us for quite a long time. Too heavy management will kill all activity. Heavy management systems tend to be too complex to use in situations where simplicity and quick input is wanted and needed. Remember the rule K-I-S-S; Keep It Simple, Stupid.

Contributing to teams and community is about interaction. I bring my wood to the toolshop and some other brings the strings. If we interact, the result might be a music instrument. In brief, if we all play the same song, we can hear the music. Otherwise we might end up generating noise. I’d prefer music over random noise.

A community needs to have one or two annual events, which in this case are regional MeeGo Summits. Events are fun, mostly. Organizing events, such as summits, can benefit our community in different ways. Firstly, summit can function as a tool to build a family or sense of it. Bringing people together unites people and strengthens social bonds. Some may even become friends. Secondly, it breaks the routine. Our community holds meetups (those little peaks) more or less regularly in two cities (Helsinki and Tampere), but a bigger two-day event with people outside our inner circles break the routine. Even though we have meetups IRL, most of our community activities are virtual. Furthermore, local meetups are great, but they are as the word says, local. Summit will be national/regional event and will hopefully unite us in national level. Thirdly, it focuses our minds. In our case, summit is the first shared goal, which can be used to focus our efforts in one point. Fourthly, summit can help identifying the leaders. Summits are always a big effort for the community and inspires leaders and strong personalities in community. This is exactly what is happening right now. We are organizing a summit but at the same time we are building the foundations of our community in the form of various teams. Teams need members, but they also need someone to lead them.

We haven’t actually made a decision whether we have one or two summits, but my bet is that there will be only one. Why? Mostly because it’s not a minor task to arrange two-day community-driven event. It might be possible to arrange a smaller summit as the second one. Who knows, time will tell.

Focus

It is useful to focus your summit on some agenda. Heck, it’s useful to have focus on anything you do. We focused to hold hacker and developer oriented Summit. I know, that’s not very focused but it’s far better than embracing the whole MeeGo ecosystem including business and business logic related items. Remember that it’s only two-day Summit. Another approach could well be selecting one or two platforms; IVI, Handset, Connected TV, Mediaphone(?) or Netbook.You could do the selecting on different grounds: what platform has the strongest hold/interest in your region? Which platform needs most to be developed? What platform is full of hype? Ask the people in your community, they probably know the answer.

Once you have the focus, you should establish a task-force to work with the program. Invite 3-4 well-connected and respected developers (or what ever fits your focus) to the team. They don’t all have to be hardcore kernel hackers. Keep the team rather small, because even with such a small crowd, you’ll get a lot of opinions and desires.

Selecting appropriate team members

We had luck when selecting people to program task-force and the timing was right. We invited Timo Härkönen (timoph) because he’s very well known developer in the community. He knows just about everyone who’s worth to know :) Besides he has a lot of hacker attitude and works with the OBS and Quality Assurance. Another person who we invited was Jukka Eklund, a very vibrant man full of ideas and enthusiasm. He’s our insider man in Nokia. A colleague, Matti Saastamoinen (smoinen) was invited to the task-force, because he has a lot of experience in organizing summits. He was involved in organizing aKademy 2010 here at Tampere. Since the facilities are the same in our Summit as they were in aKademy, Matti has significant amount of tacit knowledge related to venue site. He also participated MeeGo conference in Dublin, which is another benefit.  The last member in the task-force is Henri Bergius (bergie), who’s visions and judgement are without a question high quality. He’s also very well-known in the development circles. In other words, we focused the selection to those people who are well-connected to other developers and who are experienced in FOSS development. We considered  to get one ’suit’-member, but it never happened.

Working methods

Most of the task-force work has been virtual. We have written emails to each other and discussions on IRC have been very common. We did create a mailing list for the task-force mainly because it was possible in our domain (meegonetwork.fi) and because it simplifies mail exchange. Me and Matti have used Pidgin a lot, because it’s the common real-time discussion method in our company. We have created a shared document (google doc) in which we build the summit program. There has been additional shared documents, but the program document has been central for our work. The program was by the way originally a copy of MindTrek conference program and we just edited it. Eventually it has become totally different than what it used to be and reminds the original only faintly.

We didn’t plan to have lots of pre-scheduled real life meetings. Meetings in real life were scheduled if and when they were needed. We decided to get 2-3 “hot” speakers first as baits. Then we spread the word about those few and gained the attention of other speakers. Finding suitable speakers requires some amount of tacit knowledge about the community and significant amount of emails. I managed to get a few speakers, but it was not easy for me. I was not known in the community and I didn’t know anyone personally. Needless to say that I did not have met anyone in real life. Despite that, I gained strength from others and from the success we had with the ‘baits’. Success generates more activity and success. Once we got some speakers, the community began to do their recruiting and proposing speakers to us. Keep in mind that people come to summits to see and hear presentations and speakers, but it is important to have lots of breaks in your program! Participants of previous summits and conferences have enjoyed long breaks which offer opportunities to meet other people and have fruitful conversations.

All the above represents prebuild activity. Members of our community have suggested additional program and activity. Ad hoc presentations and workshops, or as we call them, hackshops are taken into account. Summit participants will have lounges and small meeting rooms to arrange own activities. We encourage people to do so, because such small events will keep the atmosphere and spirit of the summit more casual. After all, summits should be fun.

We did decide early on to have three tracks and even defined loosely what the content will be. It turned out that the true nature and focus of each track formed during acquiring the speakers. Lesson-learned: keep your mind open and be prepared to adjust the program. I used local meetups (mostly Tampere) to discuss the program with community, gain feedback and ideas. Writing things such as confirmed speakers to wiki helps to keep people informed about the situation. Now the program starts to build, now what?

Additional activity

Speakers are only part of the program and don’t forget the importance of long breaks. There’s normally a party and other activities as well. Early on I came up with the idea of Meegathon. After all this is hacker and developer oriented event. Meegathon is a sort of Hackathon where participants have restricted amount of time to produce a solution or multiple solutions to a problem or need. We decided to have two categories: Quick & Dirty and Hardcore. In the latter participants are allowed to create new hardware in which MeeGo is used. Of course the participants need to build the gadgets mostly in advance and only assembly on the site.  We have arranged a small tool-shop for minor adjustments and craft-work. Quick & Dirty is a pure software category. We have agenda (for what and for which device solutions should be done) in mind for that category. It includes quadricopter (this time with MeeGo), but let’s keep that as a surprise for now. The teams will have separate working spaces/lounges in the venue site. They have access to those lounges for 24h from the start of the Meegathon (at 12:00 on Friday) to the end (12:00 on Saturday). Teams will demonstrate their solutions and inventions to the public on Saturday and best ones will be rewarded.

We could have chosen the other way of traditional CFP and get most of our speakers through that. It might have worked better, or not. We could have been more open about the program. This time is has been ‘developed’ behind the scenes. Nevertheless, feedback about the program has been good and inspiring. Again we as community have done something right. We have selected suitable focus for our event (at least on paper). We have lured great speakers to our summit, speakers who are highly valued by the community. We have successfully created correct image of the summit into peoples minds. An image which builds around two words: hacker and developer.

Our community has grown to include around 200 members. Not all the members are alike, neither do they have to be or even shouldn’t be. Prosperous community needs diversity and broadness both in membership, skills and needs. This post discusses the current member structure of our community. It also proposes some actions which might be needed to make us more diverse community in the future. Some propositions include practical suggestions.

Current situation

Our community has successfully attracted professional developers (in the figure: “Core Developers and Co-developers”) and perhaps some of the technology enthusiasts, but not the users or even the majority of “Active users”. Active user refers to those who get their hands dirty and try to understand how MeeGo works, what it can do, what kind of hacks can improve UX (User eXperience) and possibly post bug reports and contribute patches and code.
People coming to our meetups (once a month) are mostly getting paid to do MeeGo development or applications for MeeGo. We have to bear in mind that this will eventually turn upside down (more users than developers). Whether we want to stay as pure developer community (IMO it would not be wise) or not, is another question or topic to discuss. Naturally, the passive users (the big mass just using MeeGo) are still absent. That will change when devices using MeeGo come to market, which will be during the next year.It takes time, before the passive user mass emerges. Before the mostly silent users gain access to MeeGo, some technology enthusiast will establish ad hoc groups and communities. Some signs of this are already visible.

Emerging user community

The active users (free-time developers and testers) are already building their own circles and groups. An example of this in Finland is ‘MeeGo Suomi‘ community page in Facebook. They have nearly 240 ‘likes’. Of course it’s “just”  a page and “likes” can’t be compared to membership or involvement in activity. Yet it shows that local micro-communities are emerging. The above mentioned page lists information about MeeGo, contains discussions in small scale and links to member written blog entries. All this in Finnish only. Even their description says: “Suomenkielinen MeeGo-sivu”, “Finnish language MeeGo-page”. That can be seen both as strength and as weakness. Let’s take a closer look what we could learn from that community.

Native language and discussion forums

Teams are the soul of the community. They are engines which create activity and bind people together. Strategy to build teams vary, and there isn’t one model which fits all situations and needs. I’m not going to lecture about the models here. You can google them yourself or go to local library. This blog entry is about how our initial teams have been formed.

Laissez-faire or intervention?

Should we just let the teams emerge by themselves or should someone do some butt-kicking? In our case, it’s both. The summit 15-16th Apr 2011 is one of the focus points in our current activities. The summit isn’t that far away and there’s a lot of things to do and arrange. Therefore I did not wait for the teams to emerge, but set up a few teams and invited active people to lead the teams. Team lead selection follows the procedures in meritocracy.  In other words people are rewarded for things they do,  not what they say or how they dress. Talks and discussions are good, but nothing gets done without some real actions. The invited team leads had shown desire (by doing things that needed to be done) to do things, not just talk.

A meritocracy is a system of government which allocates power according to ability (merit) rather than other factors such as wealth, social position, or number of votes. [Elliot Lee]

This is possibly far from the optimal situation, but the world rarely functions in optimal order. Compromises are needed.  I would have preferred that people could have found their teams in their own time, but at the moment time is luxury we don’t have. Some of the teams which currently work for the Summit, will remain as ‘core’ for the community. One of those surviving teams is ‘Communication & Tech Team’. It was the first team we started, since fluent communication is vital to our community. Some of the teams will be active only now and perhaps before the 2012 Summit. An example of such team or task-force is ‘Program Task Force’. It ‘lives’ for the summit. The Summit is a shared goal for us, much like alpha version of a program would be for some other community. It glues us together and gives us direction.

Teams and team lead

Successful teams always have someone who leads it. It can be assigned person or someone who just claims the position, either way works but latter is IMO preferred.  Claiming the lead position does not need to be formal like saying :’I'll lead the team’. It can be a lot less formal and be visible in action ie. someone begins to do tasks which normally belong to team leads, such actions as defining and scheduling things to do. People are more prone to join a team which has a direction and at least some clarity what needs to be done and when.

Some people join two or more teams for various reasons. They might be still looking for the ‘right’ team or just wish to be involved in multiple teams. These people might sometimes look like wanderers, but they are needed.  They are key elements of your community. Why? Because they enable communication between teams, which might otherwise be somewhat separate.

People from Tampere do a lot, which is not a surprise for two reasons. Firstly, Tampere will host the first MeeGo Summit FI and it is natural that members from Tampere will have more tasks because they know the limitations and possibilities of Tampere. Secondly, they are close to me so they live in the danger zone :) It’s easier for me to approach members from Tampere with kind requests to do stuff, because I have met most of them many times in our local meetups in Tampere. The intention is not to hoard tasks and positions to Tampere. I have managed to recruit members to teams outside Tampere. As I mentioned in previous blog entry, I visited Helsinki MeeGo Network in December 2010. There I held a small presentation about the Summit; what it is and how we plan to arrange it. Two persons approached me with enthusiasm. Those two were: Henri Bergius and Jens Wiik. The latter became Marketing Team lead (because was interested about it) and Henri was invited to Program Task Force (because of his extensive experience, connections and great personality). How come I need to recruit people to participate? Perhaps one reason is the rather limited time before the summit. People need to digest things before jumping in. They were uncertain about whether we even form a regional community and what it will be. Things take time in Open Source communities, which does not however justify lazy information sharing.

I am confident that teams will arise in the future without any intervention. They just might need community manager to take the rudder once in a while to maintain correct course. The role of community manager is not to make all decisions for the teams or the community. Community makes decisions in meetings. Community managers role is to enable community and team building and functionality. In brief, community managers should intervene team activity as little as possible (minimal intervention).

You can read more about our teams from here: Summit Organizing Teams. Teams need more members. Your contribution can be big or small, it’s up to you.