Meeting Sun KK in Japan on Community — however it’s defined
My Japan trip was full of meetings, as trips to Japan usually are. One of the most interesting ones was at Sun Microsystems K.K.’s site, with a number of people engaged in building Japanese communities for Sun.
Takashi Shitamichi, Yoko Suga, Natsuki Wakabayashi, Jim Grisanzio,
Hiroshi Yamaguchi, Satoshi Kawai, myself, Toshiro Umetsu, Takanobu Masuzuki
From Jim Grisanzio and others, I learned that Japan is Sun’s most active blogging country outside the US, on blogs.sun.com. And I got reminded of the messages heard many times at numerous Sun meetings: That Sun has Community experts both in Marketing and Engineering. On the contrary, MySQL’s Community Team is a separate entity, outside of both Marketing and Engineering, but serving them both.
And that’s an area where MySQL and Sun has a lot to discuss about, in order to understand if there is something to learn from the other party, and how the learnings can be applied and implemented in practise.
There is at least one area where MySQL can learn and contemplate how to implement Sun’s practices: Developer Marketing. We have never used those two words in combination at MySQL, which at times also means that a certain group of MySQL users fall between the cracks — those who contribute to the MySQL community but work for commercial customers. The Community Team socialises with them at Dev Mtgs (such as in Heidelberg last year) and at the Users Conference, and so do the Sales Engineers, Support Engineers and everyone else working for MySQL. Yet, spending time isn’t the same as concerted efforts.
Conversely, the concept of “user” seems to be different at MySQL and Sun. At MySQL, “user” is often used to mean “non-paying customer”. And these users form the core of the charter of the Community Team. We want to smoothen the way for our users, we want them to use MySQL, to expand their usage of and benefit from MySQL, and to share their positive experiences with the rest of the world. And while working on this, the MySQL Community Team strictly does not have an agenda of convincing the users to pay for something, ASAP. Sure, we want our pay check, and sure, we want MySQL (now Sun) to prosper financially. But our main goal is to fill the invisible pipeline of users who may take months or years at the user stage, before even considering to become paying customers.
Some of this forces top management to have quite a strong belief in the good that a community can have for a company. I’m thinking about metrics. It’s not as if there would be ideal metrics for community building. Or rather, there are ideal metrics, such as the number of project wins, i.e. cases where MySQL is being adopted in new projects. That would be highly relevant to know, segmented by various types of organisations. But we don’t have access to those numbers. Forcing people to register won’t work, and voluntary registration gives only a fraction of the new projects as well as a fraction of the relevant data.
My personal conclusion is that I’d rather have a high adoption rate, than know exactly which low adoption rate I have.
And another personal conclusion is that I’d generally rather spend time increasing adoption further, than increasing my level of knowledge of that adoption. That conclusion is less easy to defend, though, as some level of knowledge about adoption rates is essential.
What’s again easier to defend is that exact knowledge about an irrelevant aspect of the adoption rate may fool one to believe that said aspect is relevant. How significant is download rates? Web page hits? Email list traffic? Number of blog postings? Forum entries? And how much of that is directly driven by the efforts of the Community Team, rather than events outside the control of that team (such as new releases, security holes, acquisitions by Sun)?
Looking forward to various discussions on this topic with Ian Murdock and many other colleagues!
Reference:
- Jim Grisanzio’s blog at http://blogs.sun.com/jimgris/entry/mysql_meeting_at_sun_japan
Leave a Reply