DrupalCamp Atlanta

http://www.drupalcampatlanta.com/
See some of the presentations from the event on Slideshare
Just want to know what Drupal is? View this video or read about the Drupal web content management system at the Drupal.org site

I missed last February’s DrupalCamp in NYC, but we weren’t looking at Drupal with any certainty that we would migrate our web presence to that platform. Since then, we’ve decided to embark on such a migration.

Why? Because Drupal is modular, extensible, flexible, social, has a huge community of developers (increasingly, library-specific developers, a la John Blyberg, who developed the SOPAC module for Drupal) who share their work and allow others to build upon it. Plus, it’s free… well, free as far as the costs of software licensing go. The investment in Drupal is one of time and expertise. But the good news is that Drupal is a content management framework designed not only to grow a web site/system, but to grow expertise.

I think that’s what’s most remarkable about Drupal. Plenty of us starting off with Drupal find its eccentricities – how you have to learn to think to work with its back-end – a bit maddening. It isn’t the most intuitive of systems to begin working with. But what tool that offers sophistication and scaling really is? What is remarkable is how Drupal began by creating a community of developers and how it recruits new ones all the time -- teaching them, bringing them up through the ranks until there are more and more Drupal developers. Drupal allows many levels of mastery and encourages collaboration. It does so through its open, non-proprietary, and modular nature. And - the more skilled you get at working with Drupal, the better your Drupal system becomes. So, with Drupal, you’re growing a system while you grow a community of system developers who will build, maintain, and extend the system.

The importance of Drupal Users’ Groups, such as the one in Atlanta that hosted the DrupalCamp I attended this past Saturday, underscores the importance of community in the world of Drupal. I needed to get a jumpstart into Drupal development and learning from other Drupal users – of all levels – was the perfect place to start. It’s not only easier for me to learn from others face-to-face, but I find it reassuring. I see the brilliant Drupal developers & then realize that they are human, that they, too, began with the same basic questions and confusion. They, too, sought advice from others in the Drupal community and – in finding it – were able to grow their skills until they became the Drupal gurus they are today.

So, what did I learn? Well, I learned only what I was ready to absorb & at my level, perhaps, that isn’t too much. But the salient “aha”s for me included:

1. How to install CCK and other modules correctly, despite the fact that every time I’ve installed Drupal, the installation has seemed to lack the location I was supposed to use to house those modules (so, in fact, CCK and similar non-core modules belong in the sites/all folder, but under a modules subfolder, which doesn’t exist upon the installation of Drupal (or hasn’t existed the couple of times I’ve tried installing Drupal) – so you create a modules subfolder in the sites/all folder, then you put your new module, such as CCK under it. (and yes, CCK WILL show up as a module for you if you instead install CCK under the modules folder that isn’t under sites/all/ but then, when you upgrade your core Drupal code, these non-core modules will be deleted out… anything in sites/all/modules will not…so USE the sites/all-based modules folder!))
2. That I could use the Acquia release of Drupal (http://acquia.com/products-services/acquia-drupal) as a way of automatically having a number of extra modules and goodies that are proven to work and play well with one another installed along with the core module and/or that I could use the Acquia Drupal-Apache-Mysql-Php stack instead of the Bitnami one I’ve been using to have it all installed from one package, including the Acquia-added goodies (http://acquia.com/downloads)
3. That I’m not too low-level to participate in the Drupal community – everyone has to start somewhere & everyone plays a role – you matter to Drupal – participate! (But don’t worry if you happen to run across someone in the Drupal community who is socially backwards and behaves like a jerk… just ignore them, jerks are everywhere online, even among Drupalers…) – per Addison Berry (http://www.lullabot.com/about/addison-berry & her blog = http://rocktreesky.com/). Drupal is not run by a hierarchical organization, nor is the world of Drupal a meritocracy. Drupal is a “do-ocracy” instead. Just do it! Even if it’s not the best/perfect. The point is that you did it. (You will get better, but if you’ve done it, that alone gives you karma in the Drupal community. So that’s why developers at every level should participate in Drupal.)
4. That I should begin lurking in IRC chat (old skool!) - http://drupal.org/irc - and following the Issues queue - http://drupal.org/project/issues/drupal
5. We’ll have to watch the development of Drupal 7 to see if it’s worth implementing on 7 or 6, given that the code freeze has begun - http://drupal.org/node/578446 … the issue of whether or not to deploy on 7 is that some modules are still not upgraded to 6 yet and it will take a while for module updates to cascade… We’ll have to give this one some thought since we’re still planning our migration, rather than already having installed any code for our new site (see code freeze slides/plan (PDF) from DrupalCon at http://drupal.org/files/drupal-7-code-freeze-plan.pdf)
6. That many pros use third-party hosts, but that a hosting provider’s shared server could be problematic performance – at the very least, you’ll probably want a virtual private server… even better, a dedicated server
7. That speed can be an issue & that I could corrupt my db if I leave the PHP.INI memory setting too high (leading to the “white screen of death” related to PHP & MySQL) – that most use a PHP accelerator like APC - http://en.wikipedia.org/wiki/PHP_accelerator
8. That another performance issue can relate to too many files needing to be loaded for the end-user from far-off servers… that if you’re image/multimedia-file-heavy, you might want to have those resources/assets in the cloud (e.g., via AmazonS3, EC2, or Rackspace cloud servers) & only the php executables and core Drupal files on your primary web server … concept of CDN – Content Delivery Network popped up in a number of sessions - http://en.wikipedia.org/wiki/Content_delivery_network
9. That you should always (ASAP!) load the updates to any/all of your Drupal installation – both the core code & the modules – simply because of the security issues that continually come up… and that you can and should delete out install and other basic text files that have info that can help a hacker get into your site (these files are not needed after installation) – see http://drupal.org/node/244642
10. Drupal is starting to become “the thing” in libraries – seriously. I talked with one pro Drupal developer who’d been hired by a Midwestern library to do their website… another person is working with libraries in South Africa to deploy what sounds like a joint catalog
    
11. But that the larger pro web/Drupal developer community doesn’t always realize what’s going on in libraries… several people I spoke to who were working on library-related Drupal projects had not heard of John Blyberg’s SOPAC (the Social OPAC module) & was surprised to learn that a library developer had put together a module for Drupal…. Another developer hadn’t heard of LibraryThing… do we need to put out a primer for IT folks/general web developers to offer them insight into library system needs?
12. That maybe we need to recruit web developer pros into our field… or lure them back. What we need in libraries is a stronger crop of systems librarians/web developers to challenge all of us to higher levels… There are more high-level library-specific IT folks now than there has ever been in the field, I’d daresay. But we need even more. [As a not-so-tangential aside, why do so many libraries still insist on assuming that “technical services” (cataloging) people can automatically be turned into IT specialists? It seems like these days that it's more the exception than the rule that someone who is so good at defining differences and absolutes -- at following strict rulesets, such as AACR2 (http://en.wikipedia.org/wiki/AACR2) or even its upcoming replacement RDA (to be released, Nov. 2009?) (http://www.rda-jsc.org/rda.html) -- has enough of a holistic perspective to integrate disparate resources into a user-centered web presence. I’m not saying that it doesn’t happen, but I’m saying that the assumption that the progression would be from cataloger to IT specialist is no more valid than assuming that any other type of librarian could be automatically moved into a systems role.] But the bottom line is that library web developers should be at the same level as other web developers if we want libraries to keep up technologically. If we can’t do it ourselves, we should hire/recruit and yes, even outsource with web developers, as needed. One presenter at DrupalCamp was a library school student, but as enthusiastic a Drupal developer as she is, she doesn’t work in libraries right now (though I tried to convince her to do so!)…
13. The key factors why Drupal projects fail: (A) Not having gotten the goals out on the table / worked out clearly with key stakeholders early on… by goals, we don’t mean the system’s functional details, either, we mean, overall, what do we need and want the system to do. This early goal-setting was KEY to avoiding scope creep. Focusing on what they wanted to achieve out of the project; (B) no accountability / 3rd-party reporting structure/project manager is built into the project. Ongoing project audits make a difference. They keep projects from going off schedule/being abandoned. (C) [This one was the strongest correlation.] If more than 90% of the Drupal modules did not work as expected or failed to meet the users’ requirements, the projects ran into schedule problems and experienced scope creep. So this means that a lack of understanding of which modules are needed to get your plan to done, the project will be in trouble. This argues for a need for Drupal expertise/experience (or sharing with others who have Drupal expertise), as well as research on, and understanding of, the modules. (D) If the non-developers didn’t understand Drupal, the projects went off-track. Projects completed on-time, without scope creep are built by developers working with technical project managers and stakeholders who “get” Drupal. (E) Larger projects (more than 1,500 pages) were highly unlikely to meet schedule, cost, and performance objectives. (F) internally developed projects get higher marks than those done via third-party vendors, which the presenter thought must have been a biased result/anomaly, because it seemed counter-intuitive, so she only mentioned this finding in answering another question (I think she may be pursuing more research into this). The background of this preso (done by the person who was an MLS student) – by Julia Kulla-Mader – she’d surveyed 25+ Drupal content administrators, back-end administrators, back-end integrators, theme developers, and code developers. (see her preso on Slideshare at http://www.slideshare.net/JuliaKM/why-do-drupal-projects-fail-evaluating-success-factors-and-when-to-use-drupal). She identified the possible flaws in her study as: the survey being slightly biased in favor of programmers, that fewer than 30 people took the survey, that survey participants were self-selected, that there was a lack of historical data (were they talking about projects using Drupal v. 5 or 6, e.g.?), and that the questions were not required.
    She used several concepts to describe the success/failure of a project:
    (a) Was all or part of the initial project (as planned) abandoned? Using this criteria, 80% of projects failed… [whether or not it was simply a single module that they decided not to deploy or a larger problem wasn’t specified… in another preso about migrating an older website to Drupal, the developer said that the migration was not necessarily a good time to introduce new functionality to your website…] She did point out that almost everyone who took the survey completed at least part of the initial project plan – total abandonment rate was very low/nil [didn’t get an exact stat here]
    (b) Was the total cost of the project within what was outlined in the project’s budget? [60% were within budget]
    (c) Was the project on schedule? [close to 50% were completed on schedule]
    (d) Did new features make up less than 15% of the deployment? [hmmm… see my notes on point (a) …]
    In sum, the key things to ask yourself before starting a Drupal project are:
    - Can you devote the time to setting project goals? For each stakeholder, what would success look like to them?
    - Can you build accountability into your project? (auditing, project manager/accountability person who is not the designer or developer checking deliverables against milestones)
    - Do you have experience evaluating modules against user requirements?
    - Do non-developers on the project have Drupal experience (even before you come up with systems specifications)?
    - How big is the project?
    A final note, from another session on migrating a legacy website to Drupal – 2 important things you should do during your migration project:
    (1) Break down the task into small, manageable steps
    (2) Document what works along the way (crucial for Drupal!!!!)
    

BTW, My raw notes are in Google docs. If you want a copy, reply to this post & I’ll post/send/share them.

All this and I got a cool t-shirt, too ($ went to support Atlanta Drupal Users' Group)! I should also point out that this was what I consider to be a very well-run event. They held it on the lovely campus of Kennesaw State University. They had excellent signage & kept most sessions in the same building (the only hitches for me were some room issues / reassignments for sessions and the fact that I have NO sense of direction paired with a lack of post-lunch coffee… but I did find a vending machine that offered an espresso). Another sign the event was well-run - Dunkin Donuts coffee & donuts at the start of the session & nice box lunch – all complementary.

Corporate sponsors who helped to underwrite the camp included: Mediacurrent, Matrix, Acquia, MailChimp, AutoTrader.com, Volacci.com (Drupal Search Engine Marketing), A Small Orange (web hosting), Microsoft, and CMS Website Services