I’ve been implementing LDP section in our portal for the past two weeks or so. We have finally got it usable enough and devices are pouring out! You can check out more details about LDP from meegonetwork.fi pages. I have written also a few blog entries about and around the topics related to LDP (one here and second here).

I asked people in July Tampere MeeGo Network meetup about whether devices should be loaned to projects being open source only or should so called closed source projects be included too. I gave a thought to things that came up, but still I can’t see very strong arguments why open source community (which MNFI and TMN) should loan devices for free for developers who wish to keep part of the results (such as source code) for them selves. I might sometimes be considered somewhat hostile towards business interests inside open source community. Nevertheless, question that must be asked is: “If you are loaning a device for free and aim to use it to create business with it (create closed source app and sell it), what are you contributing back to community?” Why should we support your pure personal money-making interests?

Of course you can say that you will demonstrate your app at meetup and show how it is done. That is great! But that is the least you should do anyway! What really prevents you to show your code too? Does your code suck? If yes, then showing it to the world might give you a chance to learn how to write better code. That is possible, if one of the fundamental values of Open source is applied. That value is incremental development. That is made possible mostly by sharing code. Keeping your  app (apparently written in low quality code) in your own hands and forbidding access to code for others is a sure way to boost your own ego and push skilled people away.

Both allowed - open source preferred

One possible solution that Attila suggested sounded pretty valid. Both kind are allowed: open and closed source projects. But there is a trick. Solution prefers open source over closed source. If open source project needs a device that is not available, but is used by closed source project, the latter must return device and hand it over to open source project. I’d suggest that device must be returned in a week. That is reasonable time to finish immediate actions and return the device. Reasoning is simple. Community can benefit/learn more from open source solutions. Yet it is better to loan devices, than let them be in storage.

There are plenty of better organizations for doing business apps. If your intention is to deny access to source code and make money out of the app (ie develop money-making apps with open source community devices!), you might better look around and find another organization.

As one of the LDP managers, I’m not saying that I will reject or neglect any of the closed source apps, but I will prefer ANY open source project over closed source approach.

During the past 9 months I have been acting as MeeGo Network Finland community manager. That time has included exciting and frustrating moments, joy and sorrow, but above all it has included a lot of lessons about what is a community manager. Here’s a few things that I have discovered.

Believe in future

When you are lucky enough to be a community manager in some open source community, make sure you believe in the goals and aims of that community. There might be times when you are the only one who can find something positive about the situation. Sometimes the situation is opposite. In other words, you are human too after all. You might loose (some of your) faith in future, but then when you least expect it, community will notice this and help you to get back on track. That is if you are lucky :) I was lucky. I lost some of my faith in MeeGo during the spring 2011, but then some of the community members supported me and expressed their belief in MeeGo’s future. That helped me to rebuild my thoughts.

Kick some ass

Every community faces moments of ’silence’. Community is there, but they need to be pushed a little bit. But be careful! Using carrots works better than stick. Even if there is a valid reason to whip the community, don’t get too tough. Be understanding, respect the fact that at least some of them are using their free-time (which it self is a sign of their commitment) to participate.

Enthusiasm is needed

Community manager who ‘just works’ for the community is doomed. Well, perhaps not doomed, but success is less probable. You have to be enthusiastic to get things rolling. You have to believe in open source communities and culture, you have to be part of the open source community. If you are too ‘old fashion business oriented’ person, don’t expect to be a great open source community manager, at least not straight away. You have to learn what open source is, how it works, what are the values and modus operandi.

Make decisions and take the blame

Obviously decisions need to be made. Every community can not be run in Linus style, where decision making is avoided. Make the decisions, it’s your job. Make sure you listen to the community first, ask their opinions and insight. No matter what you decide, it will never satisfy all. Learn to live with it. Note that decision making might take rather long time, depending on the issue. Keep the discussion alive as long as it needs, and keep the discussion in open. Don’t fall into traps like discussing community issues in closed email circles.

Be consistent, be yourself

Don’t loose your true identity, be yourself. If you are hard core open source believer, let it show. If you start building a ‘manager role’ which is different from your own personality, you will fail (in epic scale). People in your community will see through your mask. That will ruin the trust that might otherwise build between you and community. Trust is one of the most important things in open source communities. If you manage to avoid the above mistake, you are able to be consistent. That means, that others can anticipate you and your thoughts. They will learn what to expect from you. That builds trust.

Throw ideas at the community

Be bold with new ideas, throw them at the community, but be prepared that every idea will not get supported. Your task is to keep community vibrant, alive and bring new life into community activities. Just like in open source projects, you might need to do a lot of work yourself before others get interested. This obviously requires time and efforts.

Listen to the community

A good community manager listens to other comrades (or brothers and sisters). Don’t shut your ears and eyes even for a moment. Be alert and try to probe what is the spirit of community, what they are doing, what kind of stuff might get them more engaged.  Don’t get frustrated if things don’t seem to go forward in the speed of light. Sometimes community is silent, but it takes only perhaps one off-topic line in IRC and then all hell breaks loose, there is chaos, confusion and trouble, but above all there is activity.

Tampere MeeGo Network started with strong interest both from network members and companies. First 4-5 meetups gathered 40 to 50 participants. However, TMN has lost some of it’s attraction lately. Partly that is due to MeeGo Summit FI which took a lot of energy from other activities, since most members were involved as volunteer organizers. Furthermore, Summit might have ‘consumed’ some of the need to have social gatherings at least for a moment. That does not explain all though. TMN meetups have been mostly about talking and discussions. There has not been much doing.

Perhaps we should change our focus to gain more attention and regenerate enthusiasm which we had in the beginning. Some of TMN members have expressed need for more hands-on related activity. This is visible in TMN meetup web discussions:

Something more coding oriented. I personally would be interested in something like “come with your tablet and we’ll help you get started”, other guys could be interested in coding camps focused on the other areas.

[M]aybe we could do a two week cadence, i.e. keep the current timeline for the presentations and news oriented meetups, and have a “enter only if you’re willing to code” type event also once a month but with a 2 week offset.

Perhaps the answer is in focusing on projects, which are run by the community. Projects are hands-on, at least application development projects should be, and software development raises new topics, issues, skills to learn and discuss. There are multiple projects going on inside our community. Current projects can best be described as ‘one man shows’. People are scattered in own projects. There’s nothing wrong with that, but it leads to situation that skills, talent, time and resources are wasted. Perhaps it’s time to find a few ideas for joint development project and participate in that even if it is not exactly what one initially wants to do. Some ideas for joint project has already been tossed in the air. One of those is to implement sort of ‘meetup app’, which would be used for making notes about meetups.

Projects are great, but what’s the big picture?

Again I had to make another drawing about the ‘big picture’ behind the projects discussed above. And again, I failed to make a simple model (skill that I lack, but I’m working on it). After a few moments thinking I found out that we have all the pieces to build/start a joint development ecosystem. Oh yes, the current buzz word ecosystem :) Anyway, what we have in Tampere:

• individual small projects (’itch’ is there, but one hand can’t make it go away)
• lots of skills and tacit knowledge
• people have interest to hands-on doing
• two universities (one is tech) and several other high education institutions.
• lots of companies, which have business interests in open source application development
• ideas, both business origin and from community.
• facilities to use as base (New Factory) and platform for projects.
• Virtual tools to enable communication: MNFI portal, mailing lists, IRC channel (#meego-fi)
• large local app development community (TMN: over 110 members)
• connections to other open source communities (hackerspaces, LUG, vapaakoodi, Ubuntu LoCo) and organizations (such as COSS)

All that needs to be done, is to make all pieces work together. In other words, someone to function as glue-gun and shoot! Below is rather complex looking illustration how things could go.

Illustration 1: Local ecosystem to feed app development

Benefits for companies

For companies supporting the above model based development are evident (and nothing new). They can test their ideas in volunteer based projects. They can use the community to implement solutions to practical needs or at least feed the community with ideas. During the projects, people generate more skills and knowledge (tacit knowledge might turn into visible form) which can be used in own product development. Needless to say that new talented employees can be found through projects and networks. New people come in from joint networks such as local hackerspaces, Linux Users Groups and other communities.

General benefits for business

Projects create applications and skills, which can benefit open source community.  New applications can create new startups for new companies and enhance entrepreneurship in Tampere region. Some of the apps would most likely be ready for end-users and could be uploaded directly to existing (and future) app stores.

What is needed

Plan to set up ‘developer lounge’, which would have devices for development and education use has been on ice for some time now. This lounge would be located to Demola, New factory. Need for devices is evident. I stumble upon the need almost daily;  many application developers (pure volunteers and people from startups) face sudden need for different devices. Developer lounge would not be limited to include just MeeGo devices. The support would include also devices suitable for iOS, Android and others. What is needed, is some support from local companies. Someone has to maintain the facilities and lounge. Of course hardware is needed too. Devices can be bought or companies could donate those for development and educational purposes.

To sum up, we have all the pieces to boost local application development and create ecosystem that benefits all participants. We just need to sit around the round table and discuss details. I’m willing to take the challenge, what about you? :)

MeeGo Summit FI 2011 was held at Finlayson area Tampere. Keynotes were at Plevna movie theater and rest of the program - three tracks, MeeGathon competition and Intel AppUp at New Factory. Friday evening party was at Gloria restaurant, which is well-known for cougars and table-dancing opportunities ;)

This Summit was possible because we have a very active MeeGo community in Finland (MNFI) which includes nearly 300 members. Big thanks goes to Hermia, COSS and other partners and sponsors as well. On Friday we handed out 259 badges. Some appeared to venue only on Saturday. Still over 100 did not come, which is bad and good. Bad because a lot of those who really wanted to come were left out (there was over 140 still queuing). Good, because the venue was not too crowded.

Overall impression that I have is that both sponsors and attendees were happy and enjoyed the Summit. Add your opinion as comment to this blog. Some verbal feedback was even flattering. Unfortunately I did not have time to follow sessions due to several responsibilities. Fortunately all sessions were recorded, so I will have a chance to look those after Summit. Those videos and session slides will be put available to summit.meegonetwork.fi as soon as possible. Pictures from Summit can be found from Flickr (search for meegofi).

People were quit eager to tweet about Summit since I counted over 500 tweets referring to Summit (hashtag #meegofi). Some blogs wrote about Summit too, for example MeeGoExperts.com. Our event IRC channel, #meego-summit-fi, had over 70 participants. Normal community channel (#meego-fi) was reserved for organizers during the summit. Even local radio “Radio 957″ had two news about the Summit in their website. Local newspaper did call me couple of times during the Summit, but I did not have time to see if Summit ever was mentioned in Aamulehti(.fi).

Some web stats:

It is not a surprise that program was most popular just after web root. A positive surprise is that visitors do check out sponsors too.

I don’t have the world map indicating browser origin before the summit, but I remember that just before the summit (about 2 weeks or so), just US, Germany, Britain and some other countries were included as origin. After the Summit, visibility is global.

Some tweets:

Feedback from participants

We are gathering written feedback from the Summit participants and deadline for that is 30th Apr. I have taken a preliminary look at the feedback (19th Apr) and below are some parts of it. Feedback form includes 5 selection questions and two free-form fields (topics were: Improvement ideas, Additional feedback). Citations below are from those free-form questions. The amount (N) of respondents was at this moment 64.

Overall impression

Nearly half of the respondents graded overall impression as ‘great’. Slightly under 1/3 felt that event was at least satisfactory and same amount saw it as ‘excellent’. One feedback sums this pretty good: “Venues used could be a little more convenient in general, but overall, you guys did a great job making sure everything clicks from day one.”

Program

Nearly half considered Summit program great. Nearly as many felt that program was satisfactory. 5% were possibly slightly disappointed. The numbers/opinions looks good since program is often the most criticized part of any summit/conference. Some participants did not see any need for long breaks between sessions: “A 45 minutes break between each and every session was maybe a bit overkill and extended the event late into the evening“. Some considered long breaks good. Opinions about facilities divided too. Some saw that “Seminars were nicely spaced so there was also plenty of time for networking and stand-browsing, which is important.”

The content was too shallow to some participants. Some would have liked to  ”see more in-depth presentations, since there definitely were a lot of very competent people who could’ve shared some of their wisdom.” “More technical and detailed presentations“. Of course these comments represent part of the participants view. Those who were happy did not give feedback and say “Ok, content was technical enough“. Nevertheless, we will take this under consideration when planning the next MeeGo Summit FI.

One great idea found in feedback was demo corner: “demo corner for participants to show off hw hacks or apps they have developed“. This was partly the idea of Hacking space at 4th floor, but it could have been emphasized a lot more.

Summit program was packed with different topics from mobile development and OBS to IVI and embedded solutions. Intel’s AppUp was the last part of official program. More than 190 developers gathered to 4th floor to learn about application development with Intel’s tools. After the session participants (190 lucky ones who had registered on time) were directed to hacking space where they received ExoPCs. This device was given for 3 three year loan, after which…well you know :) The smile I saw on people’s faces made me almost cry. My hacker heart was very pleased. Hopefully most of them will register to AppUp developer program, join our organization (meego-fi) in developer program and publish a lot of new kewl apps! That would make another AppUp in Finland more than likely.

Location & premises

Most of the participants were happy with location and premises. Most of the critique was about the arrangements on the 4th floor: “The North and South halls were too close to each other, and the presentations disturbed each other somewhat.” There were two tracks in one big hall. The tracks were separated only with curtain and that did not obviously stop the sounds coming from one track to the other. This is something that can be said to be sort of failure, but that was the best we could do with the given opportunities. Perhaps the best comment was related to weather: “Wish really hard for even better weather next time round.” We should move Finland to better location…that would need a few more sponsors though :)

And what about next Summit?

We did not fail with this Summit, instead we exceeded the expectations of several participants. This two-day Summit is in my opinion a good example (if not reference) for others to follow. I guess it would make sense to arrange Summit again 2012. If you would like to see that happen, join Meego Network Finland (more info #meego-fi) or support us otherwise for example by blogging and tweeting about us.

Oh! Don’t forget to join our organization at Intel AppUp Developer program. Our organization is (for the sake of consistency, dm8tbr loves this;) ) meego-fi and we have over 30 developers already.

This blog entry discusses different layers of MeeGo community and roles they posses, if things would go as I would like things to evolve. Some things might seem rather bold, but I’ll try to justify my opinions as profoundly as possible. Focus is on events and who is responsible for what and why. Ok, the pyramid :) Some kind of structure is needed when community includes hundreds or thousands of members. That can hardly be denied even by hard core anarchists. Pyramid is one common way to describe structure. Those of you who see pyramid as ‘evil’ since it resembles corporate or military style management, take a look at any other FOSS project. They all have ‘pyramid’. They have masses, contributors, working groups, gatekeepers and some even dictators, benevolent or other. In my view, that pyramid is turned upside down.

The pyramid is not drawn upside down by accident. It is done for a reason. Open Source development’s strength including MeeGo community is in the people who constitute that community. At the highest level are Local MeeGo Networks (LMN). They are the foundation of our community. Second layer should be regional (/national) level networks. The ‘bottom’ is Community Office. All situations and discussions should take place as near as possible to local MeeGo networks. Only when matters can not be solved at local level or affects for example regional issues/global community issues, they should be taken to next level.

Community office is there to serve ‘higher level’ parts of the community. Community office does not exist to dictate how things are done, what forms different things take or how local MeeGo Networks should function. Community office has an important role in creating guidelines and coordinating efforts which is done by listening what our members say. This requires that members participate community office work in meetings, email discussions and other forms of communication. Messages and information must flow both ways, up to down - down to up, to ensure mutual understanding and agreement. Otherwise guidelines and such are based on hunch and gut-feeling, not on facts or needs of developers and other community members. Of course there are issues that belong to community office eg community managers. Which those issues are, depends on community at hand.

Local events

Local events refers to local meetups. Normally meetups are understood as monthly meetups organized by local MeeGo network. Topics discussed and demoed in meetups are somehow MeeGo related. But that can be boring in the long run. Local networks can organize other kind of events too. One option is to have weekend-long event. That offers more time and enables to concentrate on issues that can not be dealt with in one evening meetups. An example of such weekend event could be ‘bug munching’. Weekend could include lessons about different approaches to identifying and fixing bugs, hands-on examples with different tools and development environments. That was just an example, use your imagination and create other possibilities: weekend hackathons (combine on-site activity and virtual participation), make a visit to local hackerspace, get a new gadget, demonstrate it and let people play with it, etc. Something that breaks the routine can boost your local community and get them excited again.

Why do we need regional level?

Regional level network is responsible for handling regional events such as MeeGo Summits. It must be kept in mind that regional level body does not dictate what local networks do (just as community office does not dictate what regional networks do). Organizing national or regional event requires partners and sponsors. That is more easily done when you can speak in the name of national network, instead of one city in your country. Furthermore, if regional body is used, you might have better chance to get all MeeGo developers in your area behind the Summit. If just one local network decides to organize a summit, others might feel ‘not so welcome’ and left out or secondary.

Of course the beginning can be different even considering organizing national events. It might be (or is probable) that people from venue site will take more crucial role, but that is natural. In time people from other cities will join the efforts. But still, people in venue site will take care of most of tasks. Why? They know the area, facilities, possibilities since they live there. Furthermore they see each other often in local meetups and get bonded.

Summits are planned to bridge the gap between local meetups and MeeGo Conferences(see guideline). I think that is what Amy Leeland has said a few times and that is written in guidelines too. According to event guidelines, summits “are hosted by the community entirely and are not in any way managed or planned by the MeeGo Project”. This puts all responsibility of Summits to the hands of local (or as prefer to say regional) communities. The same guideline states that organizing Summit is greater task than organizing local meetup. Based on my experiences during the last months, I can concur to that. Current guidelines suggest that each year some local group starts the process. This suggests that summit organizing begins outside the local networks boundaries. That is of course one interpretation only.

The guideline (which is useful and great in general) also seems to assume that no summit organization teams (guideline speaks about a team) will be formed or preserved from year to year. This is where I partly disagree. I do understand that the guideline is still in progress and I have contributed to that some parts that I now criticize. That only means that lessons have been learned. Here’s a few pointers.

In my opinion the team in guideline refers to some kind of management team, which in turn creates plans for the summit and gets blessing for the Summit before starting the actual work. From whom is this blessing asked? That is still open. Guideline does not bring up any other teams , that would be part of organizing the summit. Obviously there will be, each year. There is no point inventing the wheel again year after year. Based on our experience, teams will be formed and practices such as communication and team work are established. This is were regional level body steps in. Those teams are part of national network, which is responsible for the summit. Some of those teams handle same tasks (which serve the whole national community) even between the summits. It would be unnatural to attach those teams to some local network. Besides summit planning, getting sponsors, building program, getting speakers, finding suitable venue and other tasks take a lot time, months to be more precise. Much like Summits bridge meetups and international events, regional networks bridge local networks and community office. MeeGo community office should encourage local networks to join together and support all efforts in that. Those regions that have organized a summit should collect/write down an example (reference) of summit organizing teams and what they do. This would help the others and redoing the same mistakes. In other words, sort of “dos and donts”. I am willing to be part of this process as soon as MeeGo Summit FI 2011 in Tampere is over and I have kept my well-earned vacation.

For the last month or so, most of my time has involved organizing MeeGo Summit FI. At the same time I have been preparing my PhD research about MeeGo ecosystem. I know! Some members of MeeGo community do not like the word (ecosystem) for various reasons. Some are satisfied with the term community and don’t see any need to call MeeGo project an ecosystem. I’m not going to discuss this rather semantic issue here. Instead I will focus on more funny and enterntaining issues.

A few days ago I stumbled upon ‘gource’ in one of my PhD seminars. Gource is an amazing command-line tool for visualizing commit history in a git-based code projects. Currently gource supports also SVN and Mercurial (http://code.google.com/p/gource/w/list).

While videos generated with gource might at first seem useless and fancy time consuming experiments with video codecs, that is not the whole truth. Gource can be useful at least in two ways. Firstly, it allows you to see what areas of the project are active in an easy to understand way. Secondly, it shows whether there is community around a whole project or just aspects of it. I’ll discuss that in more details later.  I wanted to test gource and see what can be done with it. This gource experiment became more fun that I expected. Just for fun, like Linus once said in cover of his book. Well, he has said quite a lot but that one fits here. Let’s get dirty!

Clone, logs and gource

I had to do some preparations in my Ubuntu 10.10. Applications needed are git, ffmpeg with x264 libs and of course gource. More information can be found here. Once the preparations have been done, we can get to business. What are the steps to take? There are three steps to take.

1. Clone project from git

Git is “a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency”(source). Ok, that’s enough of git. Obviously we need the source from which logs will be generated. The logs will be given to gource as input. I’ve selected one meego project, tracker,as target for this time. So i just cloned the repo:

• git clone git://gitorious.org/tracker/tracker.git

Git does some fancy stuff and finally you should have your own clone of the project, this time tracker. Now go to the project folder (cd tracker).

2. Create log to be passed on to gource as input

Then you need to create logs from the source. In the example I have generated a small log for the last 5 days. Simply run command (in the project folder):

• git log –pretty=format:user:%aN%n%at –reverse –raw –encoding=UTF-8 –no-renames –since=”5 days ago” > git.log

The last “> git.log” directs the output to file. Voilà! You can check what the log looks like with command ‘less git.log’. Ok, now we have the logs…now what?

3. Run gource

Next you use the log file as input for gource. I will not go to every detail about every option in the below example, but some let’s take look at some of them. Ok, here’s the command:

• gource –path git.log -s 60 –auto-skip-seconds 0.1 –file-idle-time 50 –max-files 500 –multi-sampling -800×600 –stop-at-end –elasticity 0.1 -b 000000 –disable-progress –user-friction .2 –disable-bloom –output-ppm-stream - | ffmpeg -an -threads 4 -y -vb 4000000 -aspect 16:9 -r 60 -f image2pipe -vcodec ppm -i - -vcodec libx264 -vpre slow output.mp4

Here’s a few pointers about the options to get you started:

1. Option “–path git.log” is the log file path generated in previous step.
2. Option “–multi-sampling -800×600″ enables multi-sampling and  sets the screen size.
3. Option “-vcodec libx264″ sets video codec, which needs possibly be installed/ compiled into ffmpeg (I needed).

More details can be found from the gource website or from command line (run ‘gource -H’). I did a lot of experiments to get an idea what can be done and how. I encourage you to do the same. It’s fun, yet time consuming since the rendering might take time.

After some little post-production, the ‘output.mp4′ looks like the video below, which I have named “Life of an application“:

Using gource to visualize IRC discussions.

The above is something pretty normal use-case for Gource. It was made for visualizing source code trees and commits. I just started wondering what would IRC logs/discussions look like if I would input logs into gource…I know, the whole idea sounds a little weird, but I just had to see it myself. Obviously I would need to ‘emulate’ git log format and to do that I would need to parse ’similar’ logs from IRC logs. Yet some creativity should be used.

Quick look at the logs generated from Git got me started. Let’s take an example from git log which as generated with formatting option: “–pretty=format:user:%aN%n%at –reverse –raw –encoding=UTF-8 –no-renames –since=”5 days ago”. That ouputs the following:

user:Yin Kangkai
1270704848
:100644 100644 aec16a6... e3fddb2... M	patches/pch_dma.patch
:100644 100644 2b2bc37... f9ea573... M	patches/pch_usbdev.patch

First line is obviously user name. Second line is unix timestamp. Third and fourth lines are a bit more tricky. I have no glue what the two first strings (”:100644 100644″) are in the third/fourth line, so I just thought: “might as well copy that to my logs directly. Let’s see what happens”. The third and fourth strings vary all the time. Ok, so they must be some sort of identifiers (I guessed). Letter ‘M’ might be ‘Modified’. Other letters seen in git logs were ‘A’ for Added(?) and ‘D’ for delete(?). So far so good. The last string is the folder and filename. Ok, let’s see in what format IRC logs could be parsed to :)

Obviously I can get the IRC handles from each message. I can generate timestamps for each IRC message, since the log file tells me the date (in the beginning) and time for each line in human format. I just have to reverse the date to timestamp. I ignored the varying mumbo-jumbo part (”aec16a6… e3fddb2…”). Instead I just copied same values to every line, thinking I might perhaps generate some random content to those strings later. Next one I decided to put ‘M’ as modified, since putting ‘A’ as added, would have grown the tree in the middle. The tree in the middle is channel (#meego) where everyone ‘commits’. By that logic I placed channel name to ‘folder’ and append message after that. This gives me the following:

user:MrPingouin
1296603060
:100644 100644 aec16a6... e3fddb2... M meego/test

user:Venemo
1296603120
:100644 100644 aec16a6... e3fddb2... M meego/test

user:MrPingouin
1296603120
:100644 100644 aec16a6... e3fddb2... M meego/test

user:CosmoHill
1296603240
:100644 100644 aec16a6... e3fddb2... M meego/test
... and many more

Ok, I did that with some butt-ugly perl scripting. Let’s try… Bummer! That’s no good, it does not work. Gource gives me: “gource: no commits found”. Obviously something is still missing. I should have read Gource manuals (who reads manuals? I should have), because gource accepts custom log format. Besides, at this point I found confirmation for my guessing about ‘M’s, ‘A’s and ‘D’s. Those are as I suspected, modified, added and deleted. Anyway the custom log format is as follows:

• timestamp|username|[A/M/D]path/file|color

That looks sane and simple. I don’t need the color stuff and it’s optional for gource too, so I skipped that. After I adjusted my miserable parser, it generated:

1296603060|MrPingouin|M|meego/line
1296603120|Venemo|M|meego/line
1296603120|MrPingouin|M|meego/line
1296603240|CosmoHill|M|meego/line
... and many more

Let’s test again. Yay! Now gource accepted my logs and the result is…well at least something. Not much though, but it shows people posting messages (commits) to ‘#meego’ at the center and fading away after a while. Here’s two versions of it: raw ‘footage’ with black bg and one with different time scaling (a bit weird). First the ‘raw’ version (in new window youtube)

Artistic version with different time scaling and a few days combined (in new window youtube).

While that looked nice, I wasn’t satisfied and I had still room for more ideas. What if I combine two or three channel logs from same time period and use that as gource input? That might be more fun. I took a look at the logs, both #meego and #meego-dev channels. I took one log file from each, same time period of course. Problem is that #meego-dev channel logs are mostly full of just joinings and departures. Nevertheless, I copied my perl script to another file and manipulated it (again ugly, but works) to combine those two logs. Here is a snip of it:

1298031840|raghum|M|meego.01-18-2011/line
1298059680|Stskeeps|M|meego.01-18-2011/line
1298031480|sanjeev1|M|meego-dev.01-18-2011/line
1298057220|lcuk|M|meego.01-18-2011/line
...and many more

As you might notice, I used ‘folder’ (log file name) to separate channels from each other. Then I used combined log file as input for gource. The output does not look ‘good’, and the output  is much similar as with one channel, so let’s forget that. If the two channels would have had even a little more discussions, it would look great. In addition to that gource located the items, #meego and #meego-div, quite close to each other so it was hard to see where the discussion took place.

One more thing is missing and that really bugs (or itches) me. I did not find a way to include direct messages from one person to another, while still staying on the channel. Direct messages refers to user putting handle of another person in the beginning of message line. In other words, how to make users ‘commit’ to other users in gource. Parsing those connections from irc logs is pretty trivial. One way to get that would of course be making a patch to gource. A patch that enables targeting other ‘committers’. If you come up with a solution, let me know :) I did also run some tests with longer time periods, like 5-10 days by just parsing the logs files into one. Now that IRC has been ‘discovered’ without making patches to gource, it’s time to move on. What else could be visualized with this tool?

Using gource to visualize mailing list discussions

Mailing lists of course! They are often trees,which have leafs. Once again I adjusted my miserable parser to do another thing. After a few tests, parser read one month (December 2010) from MeeGo archives and emulated git logs. In this case I decided to go for similar logs what git does, instead of using custom logs like before. Reason is that, custom log offers less opportunities to build leafs.

Anyway, here’s a sample:

user:LarryMathews
1291173184
:000000 100755 000000... 9117318... A how_to_upgrad/002396.html

user:AndreaGrandi
1291186135
:000000 100755 000000... 9118613... A Dublin_MeeGo_Weekend/002397.html

user:DaveNeary
1291191407
:000000 100755 000000... 9119140... A Dublin_MeeGo_Weekend/002398.html

Obvious first line is modified name taken from email sender field. Second line is timestamp, which was created from email date and time. Third line is rather creative combination. It includes from left to right:

1. First and second strings “:000000 100755” are static, where the latter would really be read-write rules (I quess ). That string does not make any difference in this usage, so just leave it :)
2. The third string “000000…” is static too. In the real git.logs that would mean ‘new’. If there would be some kind of other string, it would be a reference to some existing object in the tree/source. (see also item 4.)
3. The fourth string, for example “9117318…” is dynamic. I took a substring from timestamp (and appended ‘…’) to make it unique. Otherwise gource would treat to following otherwise similar object as one and neglect the second.
4. The fifth string “A” stands for ‘Add’, because mails do not (per se) modify previous messages, instead they are adding information.
5. The last string is slightly simplified topic of the email appended with “/” and message file name.

Once again I used parser output as input for gource. Result was somewhat satisfactory (in new window yuotube):

It still lacks some of the leafs, since my *cough* miserable *cough* parser is not capable of linking leafs correctly. It should make the references using the third string in third line like in git logs…but it does not. Instead it just uses static string. Nevertheless, an example was created.

Another thing that I would have liked to do, is vizualizing bugtracker :) I have the SQL query which would pull the needed data out, but not yet access to make SQL queries to bugs.meego.com. But that can be arranged, so I’ve heard. Better leave now and focus on something else…

What use is all this?

Most likely no use at all, at least not in general. But is was fun and educational for me! And that is what counts in my world.  I did test out what IRC visualization with gource can produce and what is lacking. But seriously, code visualizations like the one above could be useful to get new programmers familiar with typical ‘life cycles of an application’.

For those that have not been involved in longer software projects, it might be educational to see what actually happens in projects in the long run. Eyeballing commit history or browsing the source code tree might be less eyeopening and boring.

Sometimes the source is just a big lump, sometimes the project seems to spread around the world, sometimes there is just one person doing stuff alone, sometimes swarming occurs (multiple contributors at the same time), and so on. Lumps, bursted and swarming are pseudo terms that just popped into my mind, so don’t take those seriously.

And the IRC part? While you were looking at the first clip, did you see around 490-540 IRC handles there? No, you saw exactly 34 unique handles. Yet community statistics (Feb 2011) say that 490-540 log in to #meego channel every day. That is not a lie, they are there, but say nothing. They do not contribute to discussion, but may contribute otherwise. The point is that looking at pure statistics may give you a false feeling of activity or overall situation. The same applies to email archives as well.

This thing with gource started with the idea: “I have to try that on some git tree.” A little more was tested than just that.  Nevertheless, useful or not, part of my curiosity was satisfied…until I find another thing…oh look! new gadget!….

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.

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.

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.