GSoC: first few lessons learned

For the first time this year I have been admin for a Google Summer of code mentoring organization. Now as Google has announced the students, and while my impressions are still fresh, it’s time to share some lessons.

Don’t allow old project ideas

I allowed a few project ideas from 2010 into the 2011 list. None of them were very popular with students. I think there are two reasons:

• It’s too easy for mentors to just pick up an old idea. In the end there is a risk that the mentor doesn’t take GSoC and engaging with the students as seriously as he should and don’t get into the right mindset.
• Applying for a GSoC project is a bit of a gamble for students too: good students will look at ideas lists from several years and will notice that an idea is old and just not apply.

So, if an old idea is used (because it is still relevant), it is probably best to totally re-evaluate and write it from scratch.

Pro-active mentors = Lots of good student applications

We had 13 mentors, who fell roughly into two camps. Mentors who communicated with the students, but could have done better. Mentors who replied to students questions within a couple of days and ensured that there was communication about the proposal, the background, how to solve the actual problem, etc. Much of this discussion happened on a dedicated IRC channel. The projects by the mentors which were pro-active, had more student applications and the applications were of higher quality. As a result, the students working with pro-active mentors were more likely to win. Not entirely surprising. The lesson is, that as an org admin, it is important to work with the mentors early on and filter out proposals early if it becomes clear that the mentors behind these are may not be fully committed.

Unsolicited proposals need discussion with a mentor to succeed

We had a number of unsolicited GSoC proposals. They fell into two categories:

• The proposal just appeared with little or no discussion with the mentor; in some case no mentor could be found. Needless to say, the proposal could not succeed.
• The proposal idea was raised by the student in the community, which helped find a mentor early on. We had two such proposals, one of which succeeded.

As an org admin, the challenge is to provide ways of enabling this in a structured way.

A dedicated IRC channel and IRC meetings work

We created a dedicated IRC channel where I and a few of our mentors were present at certain times of the week for students to ask questions. The channel also was used as a channel for mentors and students to have an IRC discussion at an agreed time. We also had a timed open IRC meeting which worked very well. Maybe one meeting is not enough: probably running one at the beginning and one towards the end of the application period is better.

Build gates and motivators into your program

Having a few goals to work towards, both for mentors and students helps focus minds. The GSoC timetable does this, but this is not enough. For example, some of our mentors participated in a mentor meeting early on, to discuss and formulate project ideas. The result were well formulated ideas. The meeting also helped build relationships amongst mentors: agreeing on which students should be chosen can be divisive and knowing each other helps. IRC meetings were good to stimulate engagement between students and mentors and led to draft proposals being made available by students early. And we had mentor meetings to rank student proposals (I disabled the ranking mechanism and forced mentors to attend the meetings).

Encourage good students to hedge their bets

We had a few projects, which had 5 students competing with each other. You could end up in a situation where the top 5 students apply for one project and only one can win. If there was an engaged discussion between mentor and student, the mentor will get a feeling for such situations and should encourage students to apply for another project, or even two. However, this only really works if mentors work together and co-ordinate.

A well run program will lead to repeat applications

Despite having to turn away good students (we just had too many good proposals), we had a few students thanking us for giving them support and leading them through the process. Hopefully these students will apply again in the following year and succeed.

Getting on top of Social Networks

As community manager I should know better and regularly publish on the blog. Well, it’s been a very busy beginning of the year and taking over an existing community creates its own set of challenges. Besides community managers, I’d expect that many open source project leads which take over an existing project will face similar issues. The issue at hand this time: taking control of existing social networks.

Becoming manager of existing social networks, groups, etc.

The community I work has a presence in 40+ different social networks and other on-line services. Some support the concept of a group admin/manager. Others don’t and admin rights tend to be tied to a specific user ID. When you try and take over management of some social networks you can end up in a number of situations.

• The easy one is where there is the concept of an admin or manager: all you need to do is to ask another admin/manager to promote you to manager. Now this works easily if you your existing manager cares and knows their log-in details. Which for me was luckily mostly true.
• The more probematic case is where managing a group is tied to a specific account and manager ownership cannot be transferred: there are quite a few sites where this is the case. What you essentially need to do is: get the password and change the profile. If the profile was personal, e.g. Joe Bloggs, make it generic (i.e. changed it from Joe Bloggs to Xen Community Manager) otherwise the next person will face the same problems. I also changed the profile such that it mentioned that Joe Blogs was community manager during a specific time period. This was necessary because some of the hitsory in comments refers to Joe Bloggs, which may confuse users.
• The worst case scenario is where the management role is tied to a specific universal ID and cannot be changed (such as a Google, Twitter or Facebook ID). I was surprised to find out that there are a quite few such services. In this case, you are stuck if your predecessor has used a personal ID which he/she will want to continue to use.

It was a little bit surprised that a seemingly simple task like taking over the management of a few social networks was actually hard, tedious and rather inconvenient. Much harder than it should have beeen.

You can also run into other interesting problems:

• A previous manager may have forgotton a password
• Or their account was tied to an e-mail address which does not exist any more (because he left a few months back)
• In the meantime the account may have been disabled because an e-mail to said account bounces

From my experience dealing with the support teams from some of the free social networks and services was slow and painful; in some cases non-existent. Where there was really good support, these services obviously needed to ensure that you didn’t try and abuse the service and take over somebodies identity. A disabled e-mail address does not help there.

Thus, plan for the future

The only way how to avoid such problems is to plan for the future. Basically you need to assume that you are run over by a bus tomorrow and ask yourself the question how easy would it be for successor to get started.

Here are some tips how to do this:

• Where there are admins, make sure there are always several admins besides you. Make sure you always keep the list of admins up-to-date (i.e. replace an inactive admin with a new one).
• Make sure the list of admins is written down somewhere. Some services don’t allow you to see who their admins are: so if you don’t know you can’t contact them. Googler Analytics is an example of one of those services.
• Avoid using user IDs that are tied to your person. It’s OK to use your e-mail address if it is not used to identify your account and can be changed later.
• Be careful not to use your personal twitter, google or other ID to create a new group. In particular when you know it cannot be changed later: or when you do not know. In this case, you probably want to create an identity which is tied to the job rather than yourself.
• Make sure passwords are stored somewhere and shared with at least another person in your organisation.

Getting on top of the social media landscape

When you start in a new community, one of the other challenges is to find out what goes on on the web. The easiest way to do this, is to use commercial tools such as Lithium or Radian6 (note that by far these are not the only ones; google for “Social Media Monitoring” to find such services). Unfortunately almost all of these services are incredibly expensive and practically out-of-reach for open source users.

There are free alternatives

There are a number of free alternatives: you can use socialmention.com, which works really well if your project or community has a unique name. Google alerts also works well in this case. You start getting into trouble when your project has a common name. Well, Xen is such a common name and you will need to use complex search expressions to exclude keywords as you come across false positives. In the case of Xen, I need to exclude an ever growing list of terms such as guru, travel, incense, art, yoga, … you name it. In this case, brush up your skills on creating complex search expressions (I thought I saved a link for you, but didn’t … sorry).

However I found that even with complex search expressions, you still will get a lot of noise. So the only way how to eventually get on top of these is to use Google Reader, Yahoo Pipes or tarpipe to create yourself an aggregated stream of trustworthy sources as you come across them using search, socialmention, etc.

You should also be able to use Google Custom Search, but I have not tried this.

How do others cope?

This is it for today: my bit of recent wisdom. I would really be interested to hear how others in open source or other community managers grapple with these problems.

And, I promise that I will at least write one article per month from now on.

Moving on to Pastures New

As the Symbian Foundation is changing to a licensing organisation with no staff, I am moving on. I will start a new role as open source community manager for XEN.ORG in mid January. I am looking forward to this exciting opportunity and many of the different and  new challenges ahead.

For me this also means a departure from mobile computing and venturing into cloud computing and virtualization. I will stay however on the board of Symbian DevCo and help see it through the difficult times the transition of the Symbian Foundation has caused.

With regards to this blog: it will continue as its focus is on sharing open source and community building stories. When we set up this blog, the intention was to use it as a collaborative hub for sharing and learning about community building problems. All of the initial contributors have worked for the Symbian Foundation; so it remains to be seen whether the blog will become truly collaborative or whether it will morph into my personal blog.

In any case: if you have a good community building story or need help writing such a story, get in touch.

DevCo: Experiences saving a young community

In the last few weeks, my life and that of many of the people I have worked with for a year and a half, has undergone some drastic transformations. My employer, the Symbian Foundation, is changing from an open source foundation into a licensing organisation without staff, all websites will be closed and of course this will have an impact on the open source community around Symbian. At some point in future, Nokia will hopefully build an open source community around Symbian. For now, we do not know what this will look like.

In summer, I took on a board seat at Symbian Devco, an organisation whose aim it was to give individuals a bigger role in the Symbian open source community. DevCo is (almost) entirely independent of the Symbian Foundation. The only dependency was that the Foundation was nice enough to host the DevCo website, help out with admin work and pay for a number of legal services.

It was my hope, that DevCo could continue in the event of the foundation closing. Unfortunately this hope was put to the test before a real community could form around DevCo. Just when the first issues were raised, such as “it really isn’t good for Symbian and MeeGo if there are two different Qt implementations”, which is essentially the direction things were going, events overtook us. First Nokia did make the right decision on Qt and then came the news about the Symbian Foundation.

At this stage, it was not at all clear whether Symbian DevCo would survive. To save DevCo, we had to go through a number of steps:

• Get backing amongst the board and advisory council
• Get enough of a vote to c0ntinue
• Find a new purpose
• Find somebody hosting the website
• Find some volunteers who would run everything – some of this was previously done
• Do some paperwork

At the beginning, it looked as if we wouldn’t get enough backing together. We started a discussion and a vote and at first it didn’t seem it would go anywhere. I am pleased to say that it does look as if we will be able to continue for some time. I have been impressed by people stepping up and volunteering. It took a while to build momentum: the news that Symbian Foundation would shut down the Symbian web-sites has helped focus minds. It became clear to many of our members that there is no home for the Symbian open source community any more, at least until Nokia has made their move.

The web-site has almost been moved to a new location (we are testing at the moment and the DNS has to be changed). We have some ideas on what the new vision will be. There has been really good grassroots support and more than a dozen people who are willing to volunteer and invest a little bit of time. There has been great support from what is left of the foundation and from All About Symbian. The legal set-up of DevCo has also some positive consequences, which should help Symbian centric open source projects such as Wild Ducks.

At this stage Symbian DevCo has a fighting chance to remain and fight for the interests of its community. I will let you know when I know more. It even looks as if we may be able to keep some Symbian Foundation web services, such as the Wiki as a proper Wiki instance running.

I am rather humbled. Thank you for the support. Let’s hope we can pull this off.

A model for building communities?

For some time I have been thinking now whether it is possible to express the business and people dynamics of building communities, in particular open source communities in terms of a model that is easy to understand by software engineers and architects.

Before I go there, I wanted to share though why I think this is necessary. The background is a situation where many engineers from within the Symbian eco-system, with little hands-on open source practice suddenly faced the challenge of  becoming making open source work for them and their employers. Although there is now some really good literature out there, such as The Art of Community by Jono Bacon and the Open Source Way by Red Hat, I found that many of the people I worked with found both books too verbose, or the latter too much geared towards the use of tools and open source as a business. When I followed up with a few of our project lead, what they were really looking for was “a model of  building communties described in terms of architecturual diagrams, supported by not more than 20 pages of documentation“.

Is it possible to do this? First I was sceptical: after all open source communities are as much about people, as well as business needs and technology. People problems are often hard to express. Nevertheless, I had a first go at it and managed to put a crude, but not that well defined model in place and trialled with a few people with moderate success. At the Community Leadership Summit in Portland I hosted a session with other community managers, which was interesting but we didn’t end up with a model. I participated in many of the other sessions and came to the conclusion, that this can be done. I came away with many ideas mixed with my own experiences, with a core model and its basic elements in my head and lots of scraps and ideas on pieces of paper. Some of it I managed to develop on this blog, others I didn’t as my work-life got rather busy and I had no time to pick this up.

So what next? I hope I can spend some time on the model and publish installments on this blog over the coming months. By floating the idea publicly, I am putting myself under to get going. I am confident, that there will also be lots of discussion and conversation that will influence the evolution of the model. Am looking forward to it!

On the Universe, Gravity & Twitter

For a while now, I have been thinking of writing a philisophical blog post on whether a year of Twitter usage has actually had a significant impact on my work life or the way how I generally use the internet.  If you had asked me a few weeks ago, the answer would have been a definite: hardly any impact! The main impact has been that occasionally people on twitter point me to articles which I otherwise would not have read.

The reason for this is mainly that I am not a multi-tasker. I tend to single-mindedly work on one task at a time, and usually only have one (at most two) windows open on my desktop (I may have a few minimized though). For that reason, applications such as Tweetdeck do not appeal much to me. The same is true for RSS and news readers. Although I have these apps installed, I hardly ever use them.

If I didn’t have a Twitter client on my phone, I would probably have long given up on Twitter altogether. I have been using the GRAVITY twitter client for a year: typically on the way to or from work and sometimes at lunchtime. My usage of Twitter has thus been restricted to posting interesting snapshots and photos orchids taken with my phone, the odd patchy conversation, retweeting what other people found and tweeting the occasional announcement. Not much to build up a big following. Partly a consequence of using Twitter only at certain times of the day.

This started to change for me when I came across Layman’s Take on Gravity. I decided to try Gravity’s Google Reader and Facebook support. As a consequence I use Gravity now as the main tool to keep on top of news sources for work and also privately. I use Twitter and ,more often and keep on top of what is happening on forums and blogs that I otherwise would only check occasionally. I also more often tweet articles that I read, simply by pressing a button.

Before I did not do this often because the process was too inconvenient for a single-tasker like me: having to open twitter.com or Tweetdeck, shorten URLs, copy and paste the URL, etc. etc. is far too annoying, even if you have browser plug-ins.  Many news sites on the web have widgets that integrate withT witter, Facebook, etc.: well, my consciousness filters them out like ads or I get annoyed when I click them and then have to log into another site before being able to do something.

The simple consequence is that because of Gravity I use Twitter more and that I keep on top of news (before I would check maybe once a week and then mark everything unread because I did not have enough time to check everything). In fact I am seeing clear signs of change with regards to my web usage patterns. What this shows is how powerful simple integration of social media can be. If it is simple to use,  it even has the power of changing the usage habits of somebody as single minded as me. This means that projects such as the Social Mobile Framework can have a huge impact on the life and habits of mobile users. I will certainly watch what happens with such technologies in future.

Standing out in the crowd (part 3): keep your project or package visible

The first two posts in this series looked at how to market your open source project or package looking into the question what marketing is anyway and how to tell the world that you exist. After you have followed the instructionsin those two articles, some word about your project/package is out in the world and hopefully you will have made connections with a few interested people.

Momentum and Rhythm

To ensure that all this initial effort enables you to build a real community around your open source project or package, you will need to apply the techniques explained earlier again and again in different guises. Before I go into detail, let me look at two factors that are important ingredients in building a sustainable community: Momentum and Rhythm.

The first realization is that you are more likely to attract people to an open source project if others have already visibly joined it. It’s part of human nature: everybody wants to be friends with somebody popular who already has friends; nobody wants to be friends with a loner. When I look at an open source project for the first time, I tend to check a few things:

• Is there traffic on the mailing list (or whatever communication medium is used)
• Are there other signs of activity, such as a changing news section on the web page, regular changes in the code and bug database, regular releases, etc.

By doing this I am checking whether there is activity in the project/package, i.e. whether there is momentum. Visible signs of momentum, show me that time and energy is invested into the project and thus it is probably safe for me to do the same.

Communicating with your audience using a regular and well defined time table (i.e. rhythm) can help build momentum, or at least it will create a perception that there is momentum. This works a bit like creating a sustained wave by regularly dispensing a drop of water into a bowl of water.

This analogy reveals a few simple insights:

• Release the next drop, before the wave from the previous drop has completely dissapeared. In other words, communicate while people still remember the last communication.
• The size of the released drop does not matter. In other words, it is OK to say smaller things that do not need a lot of effort more frequently.

Besides the fact that rhythm helps build momentum, it will ensure that you actually communicate. A schedule will also limit the time you spend on communicating (vs. coding) and remind you that you need to communicate. For example, you could decide that: a) once a year you will aim to talk at a conference, b) twice a year, you will release a press release as explained in part 2, c) once a month you will spend 2 hours writing something on the blog and finally d) once a week, you will spend time responding to requests in your bug databse, merging code, etc.

That means you need something new to talk about on an ongoing basis. This may sound hard, but is actually easy. Let’s look at a few ideas.

Mailing lists, Bugzilla, Code

Given that you lead an open source project/package you should encourage everybody who asks you a question to do this publicly on your mailing list or forum. If you work in a commercial open source community, such as Symbian, the likelyhood is that you are part of an existing team working for a commercial organisation.

The easiest way to show that there is momentum is to lead technical discussions on your mailing list. This can be harder than it sounds: you may need to overcome resistance or existing habits in your organisation. Sometimes you will need to force yourself to use a mailing list rather than just walking over to a colleage. If you have problems with this, put a big sticker at the bottom of the screen asking the question: Have I used the mailing list today? The bottom line is that if you do not lead by example, others won’t follow. If the mailing list shows no activity, attempts to build momentum in other ways will not have much of an effect. As a bit of a test: check out this mailing list vs. this one and assess what you feel and which community you would join after having looked at the list.

Another really easy way to show that stuff is happening at a technical level is to

• regularly publish code (rather than develop privately for months and then publish it)
• to respond to requests coming in through your bug tracker and responding to queries swiftly

An alive mailing list, code base and bug tracker are essential, but will only get you so far. These are communication channels, which are of interest to people who already know about you and are maybe looking for your project. The key question is how to engage other people and companies.

Regular News

This is where regular news comes in. The easiest way to communicate regular news is to use a blog. If you are part of a larger community, you can share a blog (as we do with this blog). If you have a blog up sign up up to at least one feed aggregator such as your community open source planet (see Symbian Community Planet, Planet Eclipse, …).

What counts as news? Almost everything related to your project/package and also about you personally. Here are a few ideas:

• If you start or finish developing a set of features, write about it!
• If a company or individual agreed to start work on bigger task in your project, write about it!
• You just completed a design, prototype, or similar write about it!
• When you publish a new release write about it with a list of what’s new and cool.
• Have you run into some interesting technical problems developing a new feature: write about it!
• You made significant changes to your web page, wiki, wish list, etc. Write about it!
• Did another project pop up that competes with you? Write about it!
• Did you go to a conference, meet some interesting people, somebody made a contribution or raised a few good bugs: write about it.
• Are you planning to go to a conference, meetup, etc. Write about it!

Anything to create a story will do: and stories related to your project/package can be short and should be easy to write. The stories do not have to be long. What is important is that you always link from the story back to your web site and/or project landing page. You also want to do this the other way round: embed RSS feeds into your landing page, wiki, website such that it refers to the latest stories. Using twitter, digg, etc. can be used to increase the impact of your stories.

Promotions

Every now and then you want to do something special to build interest. Typically when you have a bigger news story. This could be a large contribution, a new release, etc. You can consider a press release as explained in part 2 of this series.

Conferences and meetups are a good way to promote your project. Just attending an open source conference provides opportunities to talk about your project to new people. Talk to people while you are at a conference, open source convention or meetup: most are designed to make it easy to connect to people. Approach speakers after a talk, etc.  But remember: many people are at here for a purpose: so asking first why somebody is attending and bringing your story in if it fits is better than starting with “I am here because…”

Talks: You will get the most out of attending a conference if you give a talk about your project. However, often competition to get a talking slot in a conference is quite tough. It is worth remembering the following points when writing a session proposals

• Don’t make the proposal sound like a vendor pitch
• People attend conferences to learn how to do something or how to solve a problem. Make sure you explain what the attendees will learn from your session.

Even if your project/package solves a real-world problem, your chances to get a talk accepted increases if the project/package is not the focus of the submission. But, make use of the one line or one paragraph version of the project/package description which we covered in part 2 of this series. If you don’t get admitted for a talk, BoFs are often another option.

Articles: As your project/package matures and gets better known you may be approached by websites, blogs, magazines, etc. to write articles. If you get the opportunity use it! If you are part of a larger community, make use of community managers to help you review the article and promote it after it has been published!

Other simple things to keep yourself talked about

Your e-mail signature is a bit of  advertising space. Attach a signature that contains

• Project/package name
• The one line description of your project/package
• A URL to your project landing page or website

You can normally even do this if you work for a large company, but you should check with your boss. If you have a team or community, get team and community members to do the same. You probably want to use a URL shortening service such as Tiny.URL, but make sure you use a custom URL alias. Most URL shortening services allow you to do this.

Branded T-shirts: Many open source projects have a mascot or logo and use T-shirts. Most of them, wont have budget to print up a bunch of T-shirts. So how do open source projects do this? You can use sites such as Printfection to create tshirts that others pay for when they want it. Also if you are part of a larger community, your open source foundation may help create branding for your project/package.

Business cards are very cheap to make today. If you do not work for a company, creating some fun business cards for your project, with the one line description of your project/package, a URL to your web site/portal/landing page and a contact person (probably you). Even if you work for a company, having project specific business cards may be OK: do check with your boss.

Parties & Meetups: Parties and meetups are a a great way to connect to new people and to reward people who have worked with you. If you have a big milestone coming up, a party is a great way to celebrate. It does not have to be big or expensive. It can be as simple as in a pub or bar: all you need to do is to announce on your blog, mailing list, tweet about it, etc. It is a good idea to take pictures and use the material on your blog afterwards. And you need to have a way for people to recognize you, such as a silly hat, t-shirt or similar.

Be polite and patient!

Building a community around a project is not easy: it can take up to a year (and sometimes longer) to build up enough momentum for an open source project to take off. It rarely takes less than a year! Also, not everybody you will talk to, will become part of your community. When talking to open source leaders at the CLS the common figure of converting people that have joined your mailing lists to active contributors was about 3-5%. People will come and go.

This means that if there is significant progress, the experience will be very exciting and exhilarating. When progress is slow, things can get frustrating. One piece of advice to remember is: always be considerate and polite! Choose your words carefully and gently. At the end of the day, community is often about people and people issues. This means that being polite goes a long way!