Submitted by Benjamin Melançon (not verified) on Thu, 01/31/2008 - 07:41.
Just the other day, Seth Godin wrote that what organizations should strive for – and this is even truer for an open source free software project – isn’t a marketing-driven brand but good community interactions across the board. The end of Whatcott’s post says much the same, but I also like the way Godin puts it:
the real asset most organizations can build isn’t an amorphous brand but is in fact the privilege of delivering anticipated, personal and relevant messages to people who want to get them.
… what people really want is the ability to connect to each other
Sounds like the Drupal way. As a community and not a company, making everyone’s interactions with Drupal when they choose to talk to us cannot be ordered from above, it hs to be something a critical mass of us buy into (true so far).
This goes far beyond being nice to newbies in forums and IRC, I think. The code (quality and functionality) itself is key, and easy extensions and upgrades are too. But beyond that what we as a community can do to make sure people have the best Drupal experience wherever it occurs (and don’t get burned by Drupal) is share business best practices, from deploying Drupal to working with clients to billing.
(Side note: until recently, I simply assumed people would not know what Drupal is. Now I see crazy things on mailing lists like “Drupal is the new Microsoft” for nonprofits. More than ever, delivering is more important than marketing, and a community-wide attention to meeting the needs of people who are already turning their attention to Drupal is the most important way to approach the branding question. Not that we can’t also pick a new slogan and have awesome flyers and stuff!)
Afterthought: Documentation is probably the most important way people will meet their needs. Is their no documentation session proposal for Boston 2008 DrupalCon yet? Should we make a documentation-team led effort an emphasized part of the code sprint?
Just the other day, Seth Godin wrote that what organizations should strive for – and this is even truer for an open source free software project – isn’t a marketing-driven brand but good community interactions across the board. The end of Whatcott’s post says much the same, but I also like the way Godin puts it:
the real asset most organizations can build isn’t an amorphous brand but is in fact the privilege of delivering anticipated, personal and relevant messages to people who want to get them.
… what people really want is the ability to connect to each other
Artfully excerpted from Seth Godin’s “Tribe Management” post.
Sounds like the Drupal way. As a community and not a company, making everyone’s interactions with Drupal when they choose to talk to us cannot be ordered from above, it hs to be something a critical mass of us buy into (true so far).
This goes far beyond being nice to newbies in forums and IRC, I think. The code (quality and functionality) itself is key, and easy extensions and upgrades are too. But beyond that what we as a community can do to make sure people have the best Drupal experience wherever it occurs (and don’t get burned by Drupal) is share business best practices, from deploying Drupal to working with clients to billing.
Shai Gluskin has proposed a Working With Clients session at DrupalCon and I hope to see more efforts to capture this knowledge, which is often shared on the Drupal consultants list.
(Side note: until recently, I simply assumed people would not know what Drupal is. Now I see crazy things on mailing lists like “Drupal is the new Microsoft” for nonprofits. More than ever, delivering is more important than marketing, and a community-wide attention to meeting the needs of people who are already turning their attention to Drupal is the most important way to approach the branding question. Not that we can’t also pick a new slogan and have awesome flyers and stuff!)
Afterthought: Documentation is probably the most important way people will meet their needs. Is their no documentation session proposal for Boston 2008 DrupalCon yet? Should we make a documentation-team led effort an emphasized part of the code sprint?
benjamin, Agaric Design Collective