Laura's posts appearing on Planet Drupal

Laura Scott's posts that appear on Planet Drupal.

Why I'm voting for whom I'm voting for in the Drupal Association election

old voting machine

For those who don't know: I served on the DA Board in 2010-2011, and was on the Governance Committee that developed the new structures. Before that I was in the General Assembly. I'm currently on the Advisory Board.

But I share my opinions here as a long-time member of the Drupal community who cares about the future of Drupal.

Criteria: more than good intentions

Last year, the Nominating Committee (on which I served) considered many aspects when evaluating potential candidates for the Drupal Association Board, including (in no particular order):

  • Skill sets. (We needed people with diverse areas of expertise, be it financial, legal, organizational....)
  • Competence in their field. (We wanted A players.)
  • Industry. (We did not want to have a Board comprised of mostly Drupal consultants, for example. Given that consultants as a whole tend to be more active in Drupal than others, this is an issue we will always face. Even so, the perspectives of various sectors are valuable — government, publishing, education, not-for-profit, corporate, etc.)
  • Company. (We had a rule that we didn't want any one company represented by more than one Board member. This eliminated a handful of otherwise very qualified candidates. We made an "exception" with Angie Byron, because of her fabulous community leadership and because Dries, under the Bylaws, automatically has a seat on the Board.)
  • Geographic diversity. (We knew we had to reach out worldwide. This made for a challenge, because of the greater travel requirements that come from having Board members scattered across the globe, but considered it worth trying.)
  • Drupal Ecosystem. (We wanted the various perspectives of the members of our community: volunteers, small shops, large shops, large integrators, in-house teams, designers, end-users, etc.)
  • Outside perspectives. (We needed to reach outside of our own Drupal echo chamber so we could draw upon knowledge and expertise from, e.g., other FOSS organizations who faced similar challenges already.)

I am looking at the same things when considering the nominees who have put up their names for at-large Board members in 2013, but here are a few criteria that, for me, weigh higher than the others this year:

  • Skill sets and expertise. And in this, I mean awesome track record, not impressive resumes. Whether elected by the community or recruited through the Nominating Committee process, all of our Board members need to be A-players, not well-meaning B- or C-players. We should expect nothing but excellence from our elected Directors.
  • Geographic diversity. The DA is clearly still very heavily weighted towards a North American perspective. To me, the long-term viability of the Drupal Association depends upon geographic diversity of its decision makers, and right now I feel non-North American voices are needed. We're a global community, but how that's reflected in the DA Board is ... incomplete. I'm looking at non-North American candidates first.

However, with all that said, criteria for selection are only half of the equation. It behooves us all to consider....

The business of the Drupal Association

I feel it's best if those of us voting consider what the Drupal Association is doing, and what very real challenges the Board faces, before weighing the candidates to the above criteria (or whatever criteria you bring to bear). Here are just a few items.

DrupalCons are the bulk of the "business" of the DA

Just look at the financials to understand how the DA lives and dies by the financial success of DrupalCons. All of the other things the DA does, such as supporting the infrastructure, migrating project repositories from ancient and crappy CVS to Git, and the ongoing improvements of our tools available on all of these are dependent on DrupalCons' ongoing success.

How to make DrupalCons more successful is an open question. But consider:

  1. The rapid growth of DrupalCons has been a huge challenge for what has been a grassroots community event. Look at the History of the DA to understand something of how we got here. The huge popularity of DrupalCons is a great problem to have, but it's still a problem – a very real problem.
  2. The DA has put on only 2 DrupalCons a year, and because of size, each event effectively puts the entire organization at risk. With 7-figure budgets, risk can't be avoided. This means that an imperative must be put on institutional knowledge, best practices, very sound financial management, and always keeping an eye on protecting the DA. If there were a major failure of a DrupalCon, suddenly the resources earmarked for the next DrupalCon would be compromised, money to back improvements is put at risk, and the resources the DA brings to all of its endeavors are threatened.
  3. Adding a third DrupalCon represents roughly a 50% increase in activity, risk, challenges. Things didn't come together for São Paolo (and why is an open and valid question worth examination to find lessons to learn), but seem to be coming together for Sydney. The DA is obviously striving to expand the geographic diversity of major events, but that's not easy. Simply wanting more DrupalCons on more continents isn't enough. One conversation questioning how DrupalCons happen has started but that's not enough. For any such dialog to yield results, it needs to involve the Board, the Advisory Board, a lot of community members, sponsors, attendees.... And there's much to weigh in consideration.
  4. Large-scale Drupal events require significant financial commitment — much more than what your average local community group can afford. Balancing community initiative and organization against DA financial resources and risk management is always going to be a challenge on the big events.
  5. Finding ways the DA can support regional summits and DrupalCamps has been on the agenda for the Board and the Executive Director for some time now. There have been pilot programs, but there's more that can be explored. And all of these involve more than simply providing a "rubber stamp of approval".

Diversifying revenue is a gradual process

Growing other components of the DA's revenue sources, such as through DA memberships, is an imperative, but these things take time. The DA started as a way to manage DrupalCons, but our mission grew to broader support of the Drupal community. And yet, right now, DrupalCons demand the majority of DA resources and vast bulk of the DA Board's and staff's attention. DrupalCons are the tail wagging the dog. This means the great pressure on the success of DrupalCons is not going away soon. How do we grow other revenue streams to counterbalance revenues from the insanely popular DrupalCons? How do we do it without compromising the values of the Drupal community?

The DA is young — very young

Although the DA has been in existence for many years, it is very young in terms of the new governance rules. What has happened so far should not be indicative of a mature policy developed over several years. We're just getting started!

This means that whoever gets elected will be joining a small group of people who have a very heavy workload. When I was on the Board, there was always too much to fit on meeting agendas. I think it's fair to assume that has not changed at all.

Governance does not mean doing

The time for marching orders is past. The whole restructuring to the new governance model was to get away from the volunteer-doer-Board-member paradigm, because that was simply too inefficient. There's a staff of paid professionals and committed volunteers to lead implementation. What we need on the Board are people who think outside of the box, who are thought leaders, who can build consensus, who can see the big picture, who can collaborate, who can herd cats — and who have a track record being awesome at it.

In conclusion

That's all. No, I'm not going to be publicly endorsing anyone. You can decide for yourself. So have you voted yet?

Recovering contrib Image module's content in upgrade to Drupal 7

photo 3 versions

Once upon a time in the Drupalsphere, there was the Image module, which was the preferred image solution for all Drupal sites. It dynamically resized images for display, so you could upload one image and get other sizes. But it was limited to one image per node, which made it hard for situations where you wanted to insert several images into one article. All kinds of workarounds emerged, but it was all a bit kludgey. It was nice to have something, but people were looking for something better. When Imagecache came about, it was received with much excitement, and it soon took over as the preferred image handling solution for Drupal, because you could attach several images to a node, and because it was much more performant and scalable. When Drupal 7 was in development, this functionality was considered so essential that Imagecache was incorporated into Drupal 7 core and renamed "Image". (Yeah, it can be a bit confusing if you don't know the history.)

If you were riding Drupal through those image solution shifts, it could be a bit of a rough go. In my upgrades over the years, I lost my Image node-generated posts. They were there from 2006-2007, but my upgrade to Drupal 5, when I adopted Imagecache for my images, left them adrift. I had figured those posts were doomed to obscurity, with no hooks to pull them out of database obscurity. Oh, you could see the text, but the images were gone. And if you tried to edit the node, you got no node edit form, just a blank page. I wasn't going to try to fix that for a handful of posts. I figured I just had to write them off, sacrificed at the altar of progress.

I was wrong.

I recently discovered that this content loss due to Image module deprecation has a solution. When I first saw this, I guessed it was too late for me, as I should have done this in a previous Drupal upgrade, ideally when I made the initial jump away from the Image module.

But I thought, what the heck, give it a try!

Field Converter module

It was this module I found myself looking at that got me excited.

A framework for non-CCK modules to use to convert their Drupal 6 custom data to Drupal 7 FieldAPI fields....

...Currently, Image and User terms are using this framework to migrate their data to fields on Drupal 7.

Ooh! Maybe I can rescue my Image nodes after all!

I started digging around, and learned that there is really no documentation on this. You have to read the code and figure it out.

I went to look at the old Image module in contrib, where it said on the project page:

Upgrading ... from Drupal 6 to 7: Image node data may be converted to Image fields using Field convert module; the image_legacy module (in this project's git repository's 7.x-1.x branch) provides the necessary field conversion information.

Nice! Obviously I couldn't simply enable image.module, as it would conflict with the core module's namespace. So I looked for documentation, but didn't find any there, either. I explored the Image module issues, and found Image module migration, a critical open issue with lots of discussion on just this migration need. There I saw more mention of the image_legacy module, which, as it turns out, is a module within the Image module package. People were saying it was working, albeit with issues.

Hmmmm. I had the basic elements to give this a try. I made my backups and hunkered down in my dev environment for a potentially long session.

Image -> Imagecache -> Image

Because of the namespacing conflict, it makes sense that there is no Drupal 7 image module release. You have to check it out via Git. I did that. I used Drush to install Field Converter.

I enabled the Image Legacy module and the Field Converter.

And found nothing available in any menus or admin screens. Digging around the Field Converter code, I found:

function field_convert_menu() {
$items['admin/content/field_convert'] = array(
'title' => 'Convert fields',
'page callback' => 'drupal_get_form',
'page arguments' => array('field_convert_select'),
'access arguments' => array('administer software updates'), // @TODO CHANGE ME
'file' => '',



That gave me the admin screen path (.../admin/content/field_convert), so I entered that into my browser toolbar, and a very simple screen with a couple of checkboxes appeared. One checkbox was for converting Images.

So I checked the box and submitted the form.

A few moments later, the process was done. Did it work? I went to /admin/content and found all my image nodes updated, with valid node type designations no less! The entire effort took me all of ten minutes.

Elbow grease required

When I looked at the nodes, though, the images were not there. However, when I clicked to edit a node, the form loaded, which itself was a victory, complete with the node body field, as well as the original image and two resizes listed in the File Attachments.

From there it was an easy manual remediation task:

  1. Load the Filefield Sources module, configure it to look in the folder where the old images were still residing.
  2. Edit the image node and mouse over the original image attachment link to see the actual image filename.
  3. Select that file from the Filefield Sources dropdown.
  4. Save the image node. The image was now there!
  5. Repeat for each image node.

And the cat blogging is returned! Since I had only a few dozen images, this wasn't so bad. If I had hundreds, this probably would have been a bigger task meriting exploration of some kind of batch processing.

Thank you

My big thanks to joachim for the awesome work, contributing the code for the Field Converter and Image Legacy modules, sharing a workable solution for what seemed to be a problem with no easy answer!

The theming firehose (NB for designers & front-end developers new to Drupal)

Drupal markup in a Wordle

You theme with the mark-up you have, not the mark-up you'd like to have.

That's the essential truth that designers and front-end developers new to Drupal need to understand. You don't get to construct your pages from scratch, building out essentials, never a wasted div, never an extraneous class. No, you have to flip the entire process around. With Drupal you're getting markup shot at you from a firehose, and as a themer you need to sop it all up and make it pretty. Don't spill a drop.

What this means is that, by default, you're spending a lot of time debugging the theme you're building so that it handles all the different configurations, content types, page structures, etc. that the Drupal site is throwing at you.

You have to be braced for it. It can be overwhelming. You can feel like you're drowning. Don't worry. You'll get used to it after a few months. Mostly.

Make friends with Firebug.

But wait, can't this situation be changed?

Well, kind of. You can intervene in the mark-up. You can write your own page templates. Your own fields templates. Your own views templates. Your own search templates. Your own node templates. Your own comment templates. But be warned: You're going to be working against a ton of mark-up. And you'll need to know some PHP to add your own variables — mighty powerful and nifty, but your Dreamweaver chops aren't going to help much.

You see, Drupal aims to be flexible, and it does that by throwing a zillion divs, spans and classes into the output. That means if you're not expert at CSS, you're going to be lost adrift in a sea of markup, and if you are expert at CSS, you have to learn how to see through the clutter — because when you have four or five nested divs to contain one single element, it's not necessarily obvious which one to target with your CSS. Especially if there's some nefarious Drupal core CSS already at work.

There are endeavors to make Drupal mark-up better, including in the HTML5 Initiative. But that's a slow process, and it sometimes meets heavy resistance.

Meanwhile, to get sites themed now, you may have to change how you work. Change how you view the web “page”. Get used to being the html sponge, absorbing and directing the firehose, using only the drops you want and letting the rest by without touching a thing. Let go of the idea that you're building from scratch, and get used to the mindset of diagnosing what's already there.

That's the price of power. Drupal is incredibly powerful. You need to flex your theming muscles to match what Drupal throws at you. Work through the complexity. Trust in Firebug. And don't despair. In the end, the resulting webapp is orders of magnitude bigger and badder and more kick-ass than what you could have done on your own, having 100% control but going it alone.

Is the site logo content?

A brief exchange on Twitter with Jen Simmons (@jensimmons) and Morten Heide (@mortendk) about how to best incorporate a site logo into a Drupal theme got me cogitating on this question. Jen tweeted:

...What should go is the habit of hardcoding content into the theme. #separationplease #drupalwtf


"Content"? Hmmm. This got me pondering: Is a logo "content" per se? My immediate response was in the negative. But upon further consideration, I don't think it's all that clear cut; I'm definitely less certain today than I was yesterday.

This post is a bit of thinking out loud on this question. Comments welcome! (But no need to shout #wtf, okay?)

Content or architecture

To me, "content" in a Drupal site is the content, as in nodes, comments, image uploads, embeds, etc. The content is the information. Come back to an article on kitten care a year from now and the content will be the same (or at least it should be).

The logo, on the other hand, is a graphic component of the user interface as well as the branding. The logo is the visual representation of the site identity. It may change and evolve, as logos do, as user interfaces do.

But functionally the logo in the web application is really a part of the site's architecture. The logo is "home." Redesign the site, revamp the logo, change its colors, replace it altogether — it is still "home" in terms of the functionality of the application. In that sense, it is fundamental architecture.

When planning, designing and developing a custom website, the theme is custom, a part of the entire design that includes architecture. (At least, this is the assumption I'm working from.) One typically does not move a logo around on a page willy nilly. One typically does not swap out the logo for another — not unless you're also changing the theme as well, as part of an entire redesign. The logo is a part of the whole user interface, the whole user experience, the whole compositional balance of the page. Conceptually it's hard for me to split out the logo as represented on the page itself as somehow apart. Logos have their own separate life, yes, but in a user interface context matters. One might even argue that the entire user interface is all a part of the branding, with the logo just playing one part. One might....

One of the advantages of a Drupal site is that a site administrator can actually manipulate the site architecture without touching code. This helps site building happen much quicker than it would otherwise. This admin control over architecture also can be handy for site owners, even if used only once or twice in a year. And it constitutes configuration stored in the database.

But does that make architecture "content"?

Drupal is very good at blurring the lines between functionality and presentation because of this paradigm. In puritanical (small "p") terms, it's undesirable, this blurring the lines. But in terms of usability and convenience for site owners, it ends up being empowering. Site menus can be modified, added to, deleted from. Blocks can be repositioned. The user interface, in other words, ends up being extremely malleable and subject to the whims of any user with the appropriate administrative permissions.

But is it content? I guess it depends upon what you mean by content. In terms of interaction design, I tend to view the site logo as a component of the entire user interface design, as part of the architecture in terms of functionality.

In Drupal, by default the logo can be uploaded from within the Drupal admin interface, and in that regard it's something like the other architectural elements that are exposed in the Drupal back-end. But the logo's purpose is locked in Drupal core. It links to the website "home page." The administrative control of the logo is restricted to determining what graphic will be presented as the logo. In other words, the logo ends up being merely the visible face of core Drupal functionality, the site architecture.

However, in terms of design, the logo is ideally integrated in the entire page design, and ideally is not simply a drop-in graphic, swappable at a whim. What's more, how that logo appears — i.e., what that logo's graphic image might be — depends upon the site design, which in turn is greatly affected by the device for which the theme implementation is intended. For example, if handheld compatibility is being addressed, the logo on a site viewed in a desktop browser will almost certainly be different from the logo used for users viewing on a handheld device. This makes Drupal core's logo upload functionality too limited and requiring either alteration or bypassing, because when the logo is uploaded into Drupal, you just get the one logo per theme. To swap out the logo for different platforms and devices, you'll need to do some fancy theme coding to load a different image (not easy for most), use simple CSS to force-resize the image (not considered best practice), or load a completely different theme (which is often not desired).

One way to avoid this is to skip Drupal's logo upload paradigm and load the logo's graphic as a background image. This way the logo can be easily swapped through use of @media queries in CSS for different sizes and aspect ratios, to complement responsive theming for tablets and handhelds. Incorporating site logos into web design via background images using CSS is a common practice for many web designers and developers. It certainly makes it easy to do things like :hover states and other user-feedback goodness.

But maybe that's not the best approach. For one thing, it clearly treats the logo graphic as not content. What if it is?

In terms semantic

There's some interesting debate on this.

Keith on Shubox ponders the question, considers the possibility that the site logo can be considered content. He argues that for SEO reasons a logo loaded as an image can have an alt value. This doesn't convince me because the link tag that can be displayed with a background image (the logo itself) can have alt values, too.

Stack Overflow bats around the question with some very nice discussion.

One assertion that comes up is that the logo is content semantically. Again here I'm not entirely convinced — not when it comes to interaction design (for the reasons I describe above). However, I do see the site name, which may or may not even be printed on the visible page, as semantically critical. But the logo? Not necessarily. In many ways, the semantic web is not much interested in graphic logos, but rather the identities the logos represent. —Especially if you consider that logo on the same site at the same URL may be different depending upon the device you're viewing it with.

Still, the Stack Overflow discussion and other Google hits leave me questioning my assumptions. (Oh, and Google itself loads its logo in an <img> tag as content.) I'm open to convincing on this score. However...

In terms practical

In another tweet in our brief exchange, Jen noted that if the logo is loaded on a website as a background image, "nothing will print."


It's a good point: A logo set as a background image will not print if the browser is not set to print background images, and there's no guarantee that it will. And whether you offer printer-friendly alternative pages or try to remedy the matter in print.css, it's a challenge that wild and wooly browser-world does not make easy to solve.

In other words, the background-image approach for logo placement may well serve easy adaptability to a wide variety of devices, platforms and resolutions, it risks a #fail when it comes to presenting the logo on dead trees.

(And if the logo is missing, it will be missed, which again raises the notion that logos may indeed be content after all.)

So in terms of Drupal theming, maybe the logo refrain is: don't worry, print $logo, be happy.

What is DrupalCon to you?


Yesterday, we had a Drupal Association Board Meeting to discuss upcoming DrupalCons. The meeting ran very long as we discussed and debated what criteria we should consider in selecting cities for DrupalCons in 2012, 2013 and beyond. Passions ran hot at times as we hashed out our thoughts on our evolving process for making these decisions.

  • What is the purpose of DrupalCon?
  • What components make for a great DrupalCon?
  • What factors play into selecting a city for throwing a majorly successful DrupalCon?

In the end, I feel that we made a lot of progress in this meeting. This post is not a debrief of this meeting, though, but rather is a collection of some of my own thoughts about DrupalCon, shared as a member of the Drupal community.

Growing presents challenges

As Drupal continues to grow so quickly, the Drupal Association has been working hard to adapt. The community is many times larger than when I joined it over 6 years ago, even since when the Drupal Association launched in 2006.

  • Members on are now over 1 million 515784. [I stand corrected. User id's are over 1000000, but many accounts have withered, were never used after registration, or turned out to be spammers who were blocked. And since about uid 600000 the uid numbers have been incremented by 5 2, not 1. Even so, that's a lot more than when I first joined.]
  • There are more Drupal Meetups happening around the world ... and many meetups are growing in size.
  • Drupal Camps in various cities are proliferating and growing. Many are now bigger than DrupalCons were just a few years ago.

No question: People want their Drupal, and they want their Drupal events.

Worldwide there are all kinds of Drupal community events of all sizes. For the Drupal Association, we've decided to focus our attention (for now) just on DrupalCons, as they are the most challenging to pull off, most expensive to produce, and are the only Drupal events that are primarily international in nature. Who else but the Drupal Association is in a position to produce DrupalCons?

(We've been testing ways to support regional Drupal Camps, and are looking for ways to help support Drupal Meetups, code sprints, hackathons, and other smaller community events that help people get better at Drupal and get more involved in the Drupal community. More on that in 2011....)

On the Drupal Association Board, I think we're all in general agreement that DrupalCon is about serving the Drupal community. But what that phrase "serving the Drupal Community" actually means can differ, depending upon whom you ask. Each of us on the Board has his or her own idea. This is what we ended up discussing in great depth — or as much as could be covered in 6 hours.

But difference of opinion about DrupalCon mirrors the diversity of the greater Drupal community. Indeed, yesterday, as word of our discussion got out, some people began tweeting thoughts and attitudes about DrupalCons. (I'm not going to try to characterize those tweets, or the thoughts of anyone else. We all have our own ideas. Perhaps you will share your own thoughts in comments below?)

It's about the community

Drupal is fabulously powerful software, no question. The ways it can be used to build quickly all kinds of powerful websites and web apps that otherwise would require potentially tens of thousands of programming hours to get off the ground make Drupal extremely appealing to businesses and individuals alike. I'm simply thrilled by the success Drupal has enjoyed in the online world, and delight being able to draw upon Drupal for solutions to challenges I face every day at work at PINGV Creative.

But to me, what makes Drupal a powerful force in the web design and development marketplace is the community.

When I go to DrupalCons, it's like getting a contact high. The collective energy of all these people, who are all there to learn about Drupal, get better at Drupal, meet people to work with on Drupal, hire people to work on Drupal, share what they're working on in Drupal, and just connect with other people in "real" life that they otherwise see only online, is invigorating. Code sprints, documentation sprints, theming sprints, keynotes that make you think, sessions that feed your brain, parties that help you wind down — DrupalCon is an experience in full.

As the community grows, how can DrupalCon adapt? So far, we've been making DrupalCons larger to accommodate demand. Naturally that's going to change the character of things. It takes more work to produce a DrupalCon now. A lot more work. It takes real money as well to secure the venue(s), buy the food, establish wifi for one of the most network-resource-demanding crowds of any conference per capita, build and maintain the website, handle ticket sales, staff the event, work with sponsors, and the list goes on and on.

This leaves us with a choice: Make DrupalCons small, and lock out thousands of people who want to come; or let DrupalCons grow, and find ways to underwrite the expense and effort it takes to throw a major event in a different city twice each year.

We've obviously gone the latter way, and for my part this is a good thing. The more people can get exposed to Drupal through DrupalCon, the better for Drupal. And yet it's not just about numbers. We want this to be about the community.

One commitment the Board made early on was to keep the ticket price affordable. People may differ on what's "affordable," but for me it means keeping it under about $100 per day. We want to make it easy for people curious about Drupal to drop by. We want it to be accessible to your average person living on a budget. And we have a scholarship program to provide free passes to people in particular financial need.

In short, if the event is too expensive, only the true believers who have the wherewithal to come will come, and we won't grow the community through this event. And that would be a failure, in my opionion.

But there are other ways DrupalCons can serve the community:

  • Offer quality sessions that share knowledge. This has been a touchstone for every DrupalCon ever, but this doesn't mean other kinds of sessions don't slip through. I'm not all that thrilled about brag sessions, for example, where presenters show off something, but don't really share the how or what so that the attendees actually learn something more than "Joe certainly thinks very highly of himself." Or sessions where the presenter has 10 minutes of material, and then just fields questions (if there are any). I prefer sessions I can sink my teeth into. These are the kinds of sessions I try to create when I'm presenting.
  • Provide ways for people to get involved. The code sprints are great, but lately they've had the image of being just for the elite developers — which is an essential part of DrupalCon, because when else will so many core developers be able to get in the same room for uninterrupted hours of collaboration? But also important are the quiet "coder rooms" we've had lately, where people can hunker down and get their hands dirty. And the birds-of-a-feather rooms where people can gather on a smaller scale to workshop or discuss whatever interests them.
  • Revealing all kinds of things you didn't know you didn't know. It's also exciting to see what others are doing. The community is quite huge. There's so much going on that duplication of efforts can be a real problem. DrupalCon provides a great way to connect people across continents, and expose people to all kinds of things other people are doing, including oodles of things you never even knew was happening. That is exciting, and I feel provides a rush for many of us attending. Many, if not most, of us leave DrupalCon fired up to do more. You don't get that from a forum or IRC chat.

Community is the foundation. All else comes from that — the code, the business, the cool websites….

Clients follow the community, not the other way around

To me, this is how open source works. I'm sure many won't agree with me on this point. But the Drupal community came to be before the Drupal ecosphere. Today it may be hard to discern, because clients are such a huge part of the Drupal community. Professional paid Drupal work is a major driving force in Drupal development, and we definitely want to keep that paradigm going. Drupal can't thrive if it's only a hobbyist's technology.

And yet, my view is that the clients are there not simply because Drupal is the bee's knees. Drupal is a powerful technology, no question, but it's the community that makes Drupal's technological power credible. The thousands upon thousands of people all collaborating on the commons that is Drupal are really why Drupal is so great ... or at least a hugely major reason. In choosing any open source project, the savvy client looks at the strength of the community behind it. Drupal wins because of all of us thousands of people behind it, working ot make it better. Take the Drupal code as it stands today, and back it with a community of 100 people only, and you'll see usage of Drupal flatten and eventually drop.

Nobody wants to adopt an open source technology with weak community support.

By extension, I see DrupalCon as best benefiting the professional Drupal consulting ecosphere by focusing on building and strengthening the community, rather than focusing on making an event optimized for finding clients and making deals. I say this because if we do the former, the latter follows.

Someone has to pay for it

And this gets us back to cost, because if we can't keep DrupalCons affordable to people, the events will not be doing all they can to help build and strengthen the community.

Over the years, there have been complaints about how DrupalCon sponsors have become increasingly visible. Some have asserted that the Drupal Association focuses too much attention on sponsors.

Here's the thing: When events cost hundreds of thousands of dollars to produce, someone has to pay. If we keep the ticket costs down to make them affordable to a lot of people, the balance of cost has to be picked up by the sponsors. We want sponsors. We need sponsors. Otherwise we don't have events. Or we have ticket prices 2x, 3x, 4x more expensive.

And yet I also see sponsors as community members. We don't want to use up sponsors as if they're bamboo forests, expendable and replenishable. Our sponsors are part of our community. Most of the sponsors are in fact Drupal shops that comprise an important part of our community code, design and documentation efforts. DrupalCon sponsorships are not just revenue sources, they're also a major means for these companies and organizations to engage with and contribute to the community.

Sponsorship rates have gone up as the costs of events have gone up – and (very important) as attendance has gone up. My feeling is that we want to continue to offer a very diverse range of sponsorship opportunities, so that Fortune 500 companies can pony up big money for a big presence, while smaller shops can engage at lower financial levels. Over the various DrupalCons of recent years, there's been variable success at achieving this, and we're always looking for ways to do better.

What do you think?

I'm going to wrap up this rambling post here. What do you think? What makes a great DrupalCon? What would you like to see? What are DrupalCons getting right? How would you like DrupalCons to improve? What were your favorite DrupalCons of the past? And why?



Get occasional email updates on what I'm doing (and not blogging about).

Powered by MailChimp

Subscribe to Laura Scott on Planet Drupal