With the announcement of Tizen (pronounced, I learned, tie-zen, not tea-zen or tizz-en) recently, I headed over to the website to find out who the project was aimed at. I read this on the “Community” page:
Planet maemo: category "feed:ec4eaeec3783414b0575c53865227f65"
One of the most important things you can do in a free software project, besides writing code, is to get your key contributors together as often as possible.
The post-Elopocalypse angst has been getting me down over the past few days. It’s against my nature to spend a lot of time worrying about things that are decided, done, dusted. It was Democritus, I think, who said that only a fool worries about things over which he has no control, and I definitely identify with that. It seems that a significant number of people on mailing lists I’m subscribed to don’t share this character trait.
One of the most important documents a project can have is some kind of elaboration of what the maintainers want to see happen in the future. This is the concrete expression of the project vision – it allows people to adhere to the vision, and gives them the opportunity to contribute to its realisation. This is the document I’ll be calling a roadmap.
I wrote another guest article for the VisionMobile blog last week, which just went live yesterday, titled “Open Source community building: a guide to getting it right”.
Exerpt:
Community software development can be a powerful accelerator of adoption and development for your products, and can be a hugely rewarding experience. Working with existing community projects can save you time and money, allowing you to get to market faster, with a better product, than is otherwise possible. The old dilemma of “build or buy” has definitively changed, to “build, buy or share”.
Whether you’re developing for Android, MeeGo , Linaro or Qt, understanding community development is important. After embracing open development practices, investing resources wisely, and growing your reputation over time, you can cultivate healthy give-and-take relationships, where everyone ends up a winner. The key to success is considering communities as partners in your product development.
By avoiding the common pitfalls, and making the appropriate investment of time and effort, you will reap the rewards. Like the gardener tending his plants, with the right raw materials, tools and resources, a thousand flowers will bloom.
After focusing recently on a lot of the things that people do wrong, I wanted to identify some of the positive things that companies can do to improve their community development experiences: try to fit in, be careful who you pick to work in the community, and ensure that your developers are engaging the project well. If you are trying to grow a community development project around a piece of software, then you should ensure that you lower the barriers to entry for new contributors, ensure that you create a fair and just environment where everyone is subject to the same rules, and don’t let the project starve for lack of attention to things like patch review, communication, public roadmapping and mentoring.
The original title of the article was “Here be dragons: Best practices for community development” – I’ll let you decide whether the VisionMobile editors made a good decision to change it or not.
From the Neary Consulting blog:
One of the most common issues I have seen with experienced professional software developers who start to work on community software is a reluctance to engage with public communication channels like mailing lists. Understanding the reasons why, and helping your developers overcome their timidity, is key to creating a successful and fruitful relationship with the community you are working with.
In my experience, common reasons for this timidity are a lack of confidence in written English skills, or technical skills, nervousness related to public peer review, and seeing community interaction as “communication” or “marketing” (which are not part of their job), rather than just “getting stuff done” (which, of course, is part of their job).
As part of the early bird events before the MeeGo conference this week, I ran a lollipop bridge building contest last night at the conference venue. The rules were simple: 100 lollipop sticks, a glue gun, and you have to bridge a 40cm gap, and resist as much weight as possible. We had about 40 participants, and 10 bridges entered.
There were two awards: prettiest bridge and strongest bridge. Obviously, the prettiest bridge contest was judged first.
Before...
The results were really impressive! The prettiest bridge was designed by Team Symbio, Ville Kankainen, Ilkka Maki, Henri Ranki and Márton Ekler. It was a beautiful arch bridge.
Team Symbio working on the prettiest bridge
The winning bridge, made by the team “The Unbreakables”, Casper van Donderen, Dan Leinir Turthra Jensen and Sivan Greenberg, survived the shopping basket we used as the breaking tool, with 25 1L bottles of water on top – impressive! The bridge was eventually broken when Chani tried to hang off it.
The Unbreakables - looking very smug
Some of the bridges held quite a lot of weight – and broke very spectacularly!
...and after
Some of you may be interested in a guest article I wrote for the VisionMobile blog reviewing the state of MeeGo eight months after its announcement: “The MeeGo Progress Report”
Some excerpts:
On the state of the MeeGo application developer story:
From the point of view of tools, documentation and software distribution channels, MeeGo is undoubtedly behind its primary competitors – but for such a young project, this is to be expected. The success of the project among application developers and the free software community will depend to a large extent on the project’s ability to fill these gaps and provide developers with an excellent development experience.
On the openness of the project:
[...] In the mobile platform development world, it is fair to say that MeeGo is second to none in terms of its open development model.
On comparisons with Android and iOS:
It does not feel fair at this point to compare MeeGo, a project which came into being 8 months ago, with iOS or Android, but this is the yardstick which will be used when the first MeeGo smartphone comes on the market. The project has come a long way since its inception, in particular in working towards an open and transparent development model. There is still some way to go but improvements have been happening daily.
A few days ago, I took the risk of setting off alarm bells on the GNOME developer training sessions planned for GUADEC this year. It was a risk, and comments from the naysayers reminded me that it’s easier to do nothing than it is to take a risk. I’m happy to say that the risk paid off.
Thanks to all who spread the word, a couple of prospects I was aware of confirmed their presence on the course, and I received a new group booking. The training is now feasible, and we are confirming that it will happen. There is still room on the course, and I expect to sell a few more spots in the coming days.
I did get one interesting suggestion in a Twitter reply to the announcement, and I’ve adopted it. If you are interested in attending one or two of the modules (say, community processes and the GNOME platform overview, but not the practical session or Linux developer tools), you can do so for the much lower price of €400 per module and €750 for two modules, not including a GUADEC registration.
Anyone who would like to avail of this offer, please contact me, and we will take care of getting you signed up.
Thank you all for your help and support!
http://blogs.gnome.org/bolsh/2010/06/28/gnome-developer-training-in-danger/