In the DrupalCamp Colorado 2011 keynote, Angie "Webchick" Byron mentioned that being involved in the Drupal community is one of the best ways to advertise yourself and get Drupal related work. Sometimes that's simply an extension of the old adage, "it's not what you know, but who you know," as overextended community members often pass contract and freelance work to others in the community and businesses involved in the community often recruit from those they know in the community. In the Colorado Drupal community and much of the global community, it seems that there's an abundance of Drupal work available.
All of this prompted a question in the #drupal-colorado IRC channel, "How does someone get started as a Drupal contractor or freelancer?" That seemed like a great topic for the meetup, so we devoted nearly the entire time to answering the question. Most of the discussion fell into three general categories: learning more, best practices and troubleshooting.
Learning More: Join the Community
The biggest hurdle when getting started in Drupal is the vast amount of things you don't know that you don't know. For example, you could find a good book or online video to help teach you things that you don't know... but it's really hard for someone unfamiliar with Drupal to find or distinguish a good resource from the overwhelming amount of bad information. This is one area where the Drupal community can be extremely helpful. The collective experience of the community knows where to find good resources and it's advice is built on thousands of successes and mistakes.
Since this is a meetup recap, the most obvious way to participate in the community is to attend a local meetup. Groups.drupal.org is the gateway to many regional and topical drupal groups, and is where you can find information about local meetups. For example, the Colorado group page lists information for 5 meetups around the state. The page also lists information about related events, the IRC channel, job opportunities and discussions.
Best Practices: Avoiding Landmines
One attendee mentioned that sometimes Drupal development feels like walking through a minefield, where any misstep can cause something to blow up. My response was that, "stepping on landmines isn't bad," because it's a learning experience (and when code blows up, you don't die or lose limbs). But, of course, it can be a painful experience and best practices can help you avoid the pain.
A few of the best practices that were touched on in the meetup included:
- Always have a contract. It's natural to want to work on verbal agreements, especially when most freelancers' early clientbase consist of family, friends or associates. But without a contract, it's difficult to have a clear definition of the project, what constitutes completion and payment terms. Having a contract with family or friends may seem overly formal, but it helps avoid confusion and keep relationships good.
- Offer a service, not a commodity. Many people view website development as if it were a commodity or product - you build it, deliver it and it's done. But it's never quite that simple. There are regular security updates for Drupal and related modules that need to be installed and your clients will most certainly need support. If you offer ongoing service, it gives you a chance to not only receive a bit of continuing income, but more importantly, you can build a relationship with your client. Those relationships can lead to referrals and gives you good opportunities for future work with the client.
- Carefully consider hosting your clients. Aten, like many other development shops, offers a premium hosting service to our clients, but it took careful deliberation before we decided to do so. We partner with a dedicated hosting provider, so we don't manage any server or networking hardware, but we're responsible for all the software setup and configuration. We appreciate the direct server control and our clients appreciate being able to resolve any website problem with a single call to us. They're also willing to pay for that premium service, which isn't the case with all clients. I've had past clients who have balked at paying more than $10 per month for hosting, which isn't much for a hosting provider and certainly isn't enough to cover a freelancer offering services on top of hosting. If you decide to offer hosting, ensure that your client understands the extent of your support (hours of availability and expected response time). If you're not providing hosting, make that clear to your client that they should contact the hosting provider for hosting problems. There are also managed hosting providers, such as Pantheon, who offer Drupal oriented hosting with streamlined server management for those who don't want to do their own management and setup.
- Use a development server and make frequent backups. The question started as, "Should I disable all modules before upgrading Drupal?", which is the recommended practice according to documentation. While disabling modules is the safest upgrade method, making frequent backups and using a development server to test and then deploy to the production server will allow you to address any problems in a safe environment and upgrade the production server more quickly. One of the advantages of some Drupal managed hosting providers, including Pantheon, is that have streamlined the development to production process into a few easy steps.
Troubleshooting: Project Pages
Inevitably, you'll step on a landmine or encounter a problem that may not be answered in IRC or on a groups.drupal.org page. It's good to keep in mind that the Drupal community is huge and IRC and groups are only a couple of the interactive spaces. When having problems with a specific module, it's always best to go to the project page on drupal.org and search the issue queue using the search function on the right side of the project page. If the search doesn't produce any solutions or discussions regarding your problem, create a new issue. We discussed proper issue queue etiquette at the March meetup, but to summarize, when creating a new issue, include as much information as possible, such as complete error messages, related modules you may have enabled and version numbers. This is the most direct way to report a problem to the project maintainer and also keeps a record so others with the same problem can find the solution.
Aside from information about the project and issue queues, project pages contain about usage statistics, the project maintainer and update information, which can be especially helpful when trying to choose between two similar modules or installing a module that may be in a development or beta state.
It's been said that Drupal doesn't have a learning curve, it has a learning cliff. So while there are some steps you can take by engaging the community and following best practices, in the end, the question of how to get started is probably best answered with "start climbing." Get your hands dirty and just go for it. If you've conquered the Drupal learning cliff, are midway up or have just put on your climbing shoes, post a comment below and share your experience. As mentioned earlier, information about upcoming meetups can be found at the Colorado Drupal Groups page and we hope to see you at an upcoming meetup!