Colin Charles Agenda

After checking with the relevant parties, MySQL has just submitted an application for the Google Summer of Code 2009. We’ve successfully participated in SoC during 2007, and 2008, and we’re hoping to get another shot at SoC, for our third year running.

What is Summer of Code? It means different things to many different people. If you’re a student, it means you get to hack on MySQL and the related products, and churn out code, that over eleven million people use, while you sit on the beach in your bathers! And when successful, you get a nice wad of cash even!

If you’re a mentor, it means having someone to help you write features, you’ve been wanting — someone to spend a good fourty-hours per week, hacking on the feature you most want (and its do-able within 12 weeks or so). As usual, mentors, we have an ideas page up. Mentors, go forth and fill it up.

Students, should also feel free to discuss their ideas, either on the wiki, or via the mailing list. You don’t need to apply yet (in fact, you can’t till we get accepted into the program to begin with!).

Remember, this is the year to Make MySQL Contributor Friendly (MMCF). Check the interview with Masood Mortazavi for more. So much potential for server contributions abound.

If you have any other queries, please don’t hesitate to drop me a comment, or an email at colin@mysql.com. Now, on toward happy hacking!

John Lilly, CEO of Mozilla, shares some insights and thoughts on Mozilla, and its a most interesting presentation to go through. The insights are (drizzled with some of my comments):

1. Superior Products Matter – Without excellent experience and utility, the rest is meaningless. This is true, even with MySQL – our aims and values have always been performance, reliability and ease of use.
2. Push (most) decision-making to the edges – I understand that as make sure your community has a significant voice (kind of like Wikipedia’s anyone edits policy, but there’s patrolling). He also suggests that on a regular basis, you need to have surprising innovation – things that blow people’s minds. In Mozilla’s case, there are a set of core values that everyone agrees too; decision making is with the module owners (very much like how the Linux kernel, tends to run), after all, groups have different ways of working. Mozilla has decision makers, that are even outside the “official” organisation – i.e. community has a voice. And communication, is key.
3. Communication will happen in every possible way (so make sure it’s reusable) – this means via Wikis, blogs, the bug tracker, IRC, forums/newsgroups, mailing lists, audio, video, Skype chat, real-life get-togethers, and probably more. Writing notes, and sharing them, might be useful – I’ve found that the Mozilla Weekly Progress Reports on Planet Mozilla (and especially from Zak Greant) to be really useful. I’m thinking of something similar, in the MySQL (and other Sun open source communities) scope. A lot of decisions tend to be taken up on IRC, and people go on hacking on stuff, without writing documentation (worklogs/blueprints), or consulting with the mailing lists – I guess we all have communication improvements in us.
4. Make it easy for your community to do the important things – Here the highlights are SpreadFirefox, Mozilla QA, localisation and more. A focus “to help others do more” should be the mantra of every community! I see it as very easy to translate Drizzle now, that its on Launchpad, but its not the same with MySQL. Translation, documentation, non-code related tasks tend to increase community contributions – though, what do you do when you already have an excellent manual?
5. Surprise is overrated – John suggests that surprise is the opposite of engagement, which is true – no one likes surprises, and everyone wants to feel they’re important and had a role to play when something has happened. The “inner circle” needs more participation. I remember back in the days of Red Hat Linux to Fedora… there was something called the “Fedora Merge” group, and this allowed externals to provide significant decisions towards the direction of the Fedora Project. This was eventually eclipsed by fedora-maintainers, and the various boards like FESCO, and so on. As a participant in the Merge group, I felt like I had a voice, and was part of the “cabal” (there is no cabal), or the inner circle, so to speak – decisions I made, mattered. The inner circle grew, so that everyone (a maintainer, i.e. a person who “deserved” a voice) could feel included. Similar things happened for documentation, marketing, and so on, with various members and boards.
6. Communities are not markets: members are citizens – John stats that citizens are more than consumers, bystanders and stake-holders – we are all citizens in the community (whether you’re a paid staff member, or an external). The best citizens even challenge the status quo, propose improvements and make the conversation richer – I think we have this, via Planet MySQL. The question though is, are we as Sun, listening to the citizens?
7. The key is the art of figuring out whether & how to apply each of these ideas – John suggests experimenting, trying new things, and then measuring the reaction.

Of course, back to point #6, engaged citizens are noisy is highly true. But the old adage of people complaining because they care, is probably a good thing to remember. Expect noise, demands, threats, contradictions, and more. You can’t please everyone in a healthy community, but they will help you make decisions.

A most interesting presentation, and there’s a lot to learn from Mozilla, for other communities to apply.

The Internet is a great tool, but the problem with the Internet is outdated information. I was looking to find the famous Foh San Restaurant in SS2, and while the Internet suggested it did exist, Foh San closed down in SS2 sometime in 2007. The only Foh San Restaurant that exists now is in Ipoh (not SS2), and from what I hear, they plan to open another one in SS2 or the surrounding areas sometime in 2009.

Now, back to the outdated information on The Internet. Look at dineMalaysia. It looks like it was last updated in 2004. A lot can change with regards to restaurants and bars in a period of four years. Their database is also shared with some Expat eatery site. Another catalogue site lists it, but I wonder how many restaurants on that list don’t exist anymore.

The importance of catalogue websites is that they need to be constantly updated. It has to be spurred by someone (maybe the tourism ministry?), and have the capability to be cool enough to have a community built around it. The way I see it, is it should be That’s Melbourne! with a community.

The only clue I got that Foh San in SS2 had closed was from this blog entry – “… the new Korean BBQ shop (formerly Foh San Restaurant branch)”.

This however, didn’t help me, as I had already spent time looking for it. Searching by relevancy, which can also suggest dated content, doesn’t help when there is a lack of information, does it? I see a book about Google’s search algorithms in the bookstore, but I’ve yet to pick it up. I’m just curious, how catalogue information can:

1. stay updated, constantly
2. be relevant

(1) is easy to solve… It has to involve a community. I guess that will fix (2) too… so how do you get a community involved in catalogue information? Shouldn’t be too hard considering its food and beverage related. Bottom-line is, there needs to be traction built around it…

MySQL is featured on the Google Open Source Blog
Just after leaving JavaOne, Leslie pinged me on IRC to inform me that the MySQL project was featured on the Google Open Source blog. Go on, read Moments of Inspiration.

In other news from mentors, Colin Charles, former mentor and 2008 organization administrator for MySQL dropped a note to let us know that their Community Bonding period is moving along swimmingly. So well, in fact, that their students are already delivering weekly status reports. Colin mentioned that their student Filippo Bollini had crafted a particularly well written update; it’s worth checking out for mentors wondering what sorts of information to collect from students or for students wondering what kind of details are most useful to their mentors.

Congratulations Filippo. I expect great things from you (as does Brian.)

Start your engines!
Students, and mentors alike, this is the week that the Summer of Code starts! Well, coding anyway. Its very encouraging to see all the weekly reports flow in, and once I catch a breath, I’ll be summarising them for all to see and keep up with how the MySQL SoC students of 2008 are doing.

Note: these are live notes. It was a great talk, I’d rate it as excellent (and I’m not just saying that because Josh and I work in the same group at Sun). I’ll have to also comment on his thoughts and talk, in due time. MySQL, as an open source project, has a lot to learn.

Ten Ways to Destroy Your Community
A How-To Guide
Josh Berkus, Community Guy

Part 1: The Evil of Communities

• you may attract and will be unable to get rid off a community
• they mess up your marketing plans, because the community goes out and does its own marketing and PR and distributes your software in places you didn’t expect to
• they also mess up your product plans, because they contribute to code and features to your project, with unexpected innovation!
• communities are never satisfied by any amount of quality and keep wanting to improve it – if you can’t make it better fast enough, they sometimes do it on their own!
• you have to re-define your partner and customer relationships… people who were your customers start contributing to your project, sort of making them partners… “confuse your salespeople” :)
• the worst part about having a community, is that they require to you communicate constantly (and who has time for that?). Emails, chat channels, web forums, you get constant pestering

10 Ways to Destroy (The Berkus Plan, Patent Pending!)

1. Difficult Tools

• weird build systems
• proprietary version control systems
• limited license issue trackers
• single-platform conferencing software
• unusual and flaky CMS

This will limit attracting new community, and eventually people will get frustrated with the tools and go away.

2. Poisonous people
Maximise the damage they do – argue with them at length! So if people give you problems, continue feeding the trolls. Then denounce them venomously, and finally ban them. Josh then goes into a funny way of making use of poisonous people, which eventually leaves your team and the troll(s).

3. No documentation
Don’t document the code, build methods, submission process, release process, install it.

4. Closed-Door Meetings
Short notice online meetings are good. Telephone meetings are even better, because of timezones and limited conference lines. Meet in person, in your secure office, is the best way! (even if you dial in on a conference line so that others can here). People that are most involved will leave your project right away.

5. Legalese, legalese, legalese
The longer and more complex the better! Hate and fear of attorneys help drive people away from your open source project. Contributor agreements that are long/complicated, with unclear implications are particularly good. Website content licensing, non-disclosure agreements (NDAs) [European developers usually never sign an NDA], trademark licensing terms (name and logo of your project… good way to dissuade people). Used properly, you can use legalese to keep out developers!

Bonus: change the legalese every couple of months without informing folk!

6. Bad liaison
A bad liaison/community manager is someone reclusive (least social, hates answering email, unplugs phone regularly, etc.). Also, someone with no time works very well. They’ll spend a few weeks, but pretty soon they’ll give up, and if you’re really lucky they’ll be snappy and make bad comments to the community!

Assigning someone with no authority also helps. As a community manager, you have no chain of command, and you just get to deliver bad news (we decide, and you just say something). That person usually leaves your company, and becomes a poisonous person, and its a win-win.

Someone unfamiliar with the technology also helps. An open source Java project, getting a PHP programmer, is the best person for you :)

Having no liaison also helps. Refer to the project liaison, but have no one!

7. Governance obfuscation
A good model for this is none other than the UN (He has a slide on the UNDP).

Get your legal team to write a governance document. Like they’re dealing with a hostile outsider. You’ll be impressed what they come up with!

Three principles:
1. Decision making and elections should be extremely complex and lengthy
2. Make it unclear what powers community officials and communities actually have
3. Make governance rules nearly impossible to change

8. Screw around with licenses
Licenses loosely translate to Identity. You’re not just a Linux contributor but a GPL person… You’re not just a PostgreSQL contributor but a BSD person…

9. No outside committers
I. No matter how much code outsiders write, only employees get to be committers. This is a surefire way to annoy contributors eventually.
II. If they ask why they’re not being able to commit, just be evasive! Talk about needing a mentor, decision not made yet, etc…
III. Make sure there are no written rules on who gets to be a committer, or that the criteria are impossible to fulfil.
IV. Bonus: promote an employee who doesn’t code to committer! Most will get disgruntled by this and go away and they’re not your problem anymore.

10. Be silent
He demonstrates out live, by giving him a minute… what silence really is. Just do nothing, be really silent.

Q&A

How does Sun score?
All of these techniques have been successfully employed at open source projects at Sun and elsewhere. He gave this talk at a Sun internal event and people came up to him asking if they were talking about their project! Sun is scoring pretty well, but not necessarily any better than other corporations.

I missed the question, but the answer was: If you are fast and clear about explaining mistakes, communities tend to be forgiving.

Examples of a successful community?

Kernel.org, and the Linux kernel community.

What about using forking to destroy community?

Combines poisonous people and playing with licenses. It fragments the outside community as people have no idea which to use. You can’t plan a fork (as it requires a lot of motivation to do the fork – finding people with that level of commitment and masochism is hard). Keep your poisonous people around and encourage them (poisonous people who are also code writers), then you sort of foster their image in the community by giving them a voice, and if you do something to really mess with the community’s mind (say a change of license), then the poisonous person will take the project and fork it.

The other way of forking, is to take a legitimate outside developer, build them up, and then after they have become a major developer, abruptly lock them out. The danger here is that they might not fork the project, and change the project back…

How do you prevent companies from supporting your project? Because this also means more developers will come to your project. And these companies are now selling services around your product.

Monkeying around with licensing. Then you change the commercial services around that. The second thing to prevent ISVs, is to play around with trademark rules, and lots of legalese. Prevent them to get code into your project, that should help too.