C H A P T E R  36

Now You’re in Business: Making a Living with Drupal

by Allie Micka

You’re ready to strike out on your own and become the next Drupal rockstar! There’s plenty of work out there for experienced Drupal developers, and this book has armed you with the technical foundation you need to get started. To make a living, you just need to find people who are willing to pay you to do some work. Then you do that work and you get paid. It really is that simple!

Yet many new Drupal developers find themselves struggling with miscalculations and feel unprepared when things get complicated. For the first few projects, many Drupal developers feel that they are barely earning enough to hang on, while their clients or managers are increasingly disappointed that the promise of a Drupal web site just isn’t panning out.

We want to prevent this, which means we want to plan carefully, involve everyone who should be part of the process, and work together to make each project the next Drupal success story. As you work with Drupal’s strengths and leverage the community, you might even find yourself working as a contributing member of Drupal itself.

Building a Drupal Site: New Rules for New Technologies

Drupal introduces a lot of functionality right out of the box and allows an experienced administrator to accomplish a lot with minimal effort. This power and flexibility are often misinterpreted as “Drupal will do everything I need without any effort at all.” Perhaps it sounds silly to put it that way, but we’re all capable of falling into the trap of assuming too much. And when inflated expectations collide with a developer’s inexperience, the results can be disastrous.

By contrast, a successful Drupal project is a collaboration between clients and developers that lets everyone focus on their strengths. By recognizing this collaboration and planning to work together on common goals, an experienced Drupal developer really can do a lot with a little and build a solution that works well for many years to come.

“I Hate Drupal:” Things That Can Go Wrong

It takes a lot of character to figure out what you need to learn and apply yourself to figuring it out. My day job involves helping developers and site owners become self-sufficient Drupal users. Many of our clients are just getting started and want to start on the right foot, while others are ramping up their skills for challenging new tasks. Unfortunately, we also encounter many Drupalers who open the conversation with, “I hate Drupal.”

We hear this sentiment from both developers and site owners who feel they have a Drupal mess on their hands. It’s an over-budget, overdue, overwrought enigma that just doesn’t do what it’s told. There are common themes to this disappointment, such as:

• Drupal is complicated
• A Drupal site is expensive to upgrade and maintain
• I can’t find out where to get support
• Drupal developers are expensive
• My developer vanished!

The frustrating situations that developers and clients encounter stem from applying old assumptions to a new technology. They find themselves working against Drupal rather than leveraging its strengths. Sometimes it’s just too much and an under-experienced developer, confronted with a client whose expectations are set high, switches into an avoidance mode and bugs out.

Let’s try and avoid that!

Understanding Drupal

It’s easier to harness Drupal’s power when you approach a Drupal project with a clear understanding of what it provides out of the box and what’s required to build upon it. The first step to sidestepping a problem project is developing this understanding so that you can see the warning signs when a client is making some dangerous assumptions.

Drupal and “Done”

If you were to build a fence around your yard, your first step would include taking measurements and selecting the material. You can figure out how long the installation will take based on the first few sections or, better yet, a professional fence installer can provide a more accurate estimate based on how long it takes take to dig the required number of posts and complete the project. The more experience your professional has, the more deftly they can avoid obstacles such as rocky patches of ground or gas lines. The end result will probably match what you pictured in your head before you began.

Historically, software and web development could be predicted by similar mechanisms. Starting with an empty field, a list of requirements presents a series of sections to complete. You select your materials—or programming language—and begin the process of writing function after function, file after file, and page after page until the functionality matches the requirements. It’s certainly predictable to work this way, but it can also be much more costly and repetitive, and the end product will not change as new technologies become available.

Over the years, developers have created programming libraries, methodologies, and frameworks that aim to reduce repetition. Drupal can be considered a framework, and one of its goals is to reduce coding repetition to zero. Extend the fencing analogy to a Drupal project, and it might look like something out of a futuristic show like the Jetsons (let’s pretend they had yards to fence in!). With the push of a button, a magical robotic fence unfolds before your very eyes, and in just a few seconds you’re done! Or are you?

What Does “Done” Mean?

Drupal lets you point-and-click your way to new functionality. And because so many people use and support Drupal, there’s a good chance that it’s community-tested and will work well for your needs. However, the functionality that exists may not match the specific image that a client pictures in his head. For example, when the client says, “I would like a forum on my web site,” he has a picture in his head of a forum he has used on a forum-centric web site. He is imagining e-mail notifications, quality ratings on each comment, and little animated smiley faces that automatically appear when you type “:)”.

His developer hears, “I would like a forum on my web site,” and she remembers that Drupal includes a forum module right in its core distribution. Since there’s no need to research or download any modules, she estimates that adding a forum to the web site will take just one hour. But the client is deeply disappointed when he sees the result of this effort. “Where are my smilies?” he cries!

While it’s still possible to deliver something that matches the client’s expectations, it will take much longer than the budgeted hour and will require many more modules, configuration changes, or custom theming. Someone must pay for this time. Perhaps the developer will end up working for minimum wage on a fixed bid, or maybe the client will cover the changes and his budget expectations are shattered. The process of making things right is founded on disillusionment, and everyone begins thinking that Drupal isn’t all that it’s cracked up to be.

What Does “Done” Look Like?

Imagine what might happen if you carried a photograph of your favorite dish into a well-regarded restaurant, insisting that the chef prepare something that looks exactly like the picture. By rejecting the chef’s culinary expertise you’re adding unnecessary complexity and you’ll probably end up with an inferior meal. This is what happens when design expectations are set by a graphic artist or business analyst who is not experienced with Drupal. The client may fall in love with mockups that present a specific aspect of a design, layout, or workflow that is different from what Drupal provides out of the box. The result of this is can be a costly customization project.

Does this mean that Drupal is generic, boring, or inflexible? Not at all! It’s always possible to season to taste by re-theming or restructuring the out-of-the-box functionality to meet your goals. However, you can sink a lot of time and money into chasing a specific mental picture when your goals might be addressed just as well—if not better—by leveraging what’s already available and then building on top of it.

Drupal will never be as predictable as building something from scratch, but that’s a good thing. You can leverage the experience and track record of thousands of people who are working on goals that are in common with yours, and you can profit from ideas you would never have thought of on your own.

Content Needs Managing

It was easy to draw a line between “webmaster” and “client” when a web site could be approached as a compartmentalized work effort. We could collect the content in various documents and files, put it up on the site, design some appealing graphics, and get the go-ahead from the client when it’s ready to launch. A client’s role was relegated to providing documents and confirming that they look right.

Drupal’s biggest strength is that it allows the client to become a contributing editor, content manager, or even a site administrator, limited only by his time and inclination to become acquainted with the details. With these new job titles come new skills and responsibilities that kick in well before the site goes live. If these roles are important after launch, then the people filling these roles are important during the development cycle. That’s a pretty big change from the old way of doing things.

Control over a site is a good thing, because it means current content and the autonomy to make changes without hiring a developer. And while Drupal gets easier and easier with each new release, you can’t expect to have total control without learning at least a little bit. Unfortunately, developers often forget to acknowledge the learning curve of their clients. They don’t always account for the time it takes to develop a foundation of knowledge and don’t include the post-launch support necessary to keep things running smoothly. This can leave a client feeling left in the dark, resenting Drupal rather than embracing their newfound powers.

“Now I’m Hiring Rock Stars?”

We often hear that Drupal takes a “building block” approach to site building. An experienced Drupal developer can point and click her way to victory, developing complex business applications without opening a text editor. This has obvious benefits: nearly anyone can advance to this skill level, including people who have an intimate understanding of a particular field or business process.

The big secret is knowing where to point and what to click on. Which modules should be downloaded? When should you open a text editor? You can’t just turn on a module that works as advertised; you’re often tasked with weaving together a whole bundle of modules just to perform one simple task. This idea is foreign and intimidating to new users, including new developers who make a lot of rookie mistakes and create some expensive Drupal messes.

Experienced Drupalers can get expensive, but that’s usually because they’re offsetting a lot of time spent sharing best practices and improving Drupal itself. I have seen countless projects where a single well-trained Drupal developer was able to develop an application in a matter of weeks, replacing an existing solution that cost millions of dollars to build.

This applies to small and large projects alike. Consulting with a trusty Drupal guide, if only for a few hours, can prevent a lot of drama while helping you see possibilities you couldn’t have imagined. Fortunately, it’s getting easier to prosper from sage advice. With more books, more training materials, and a variety of “prepackaged knowledge” in the form of distributions, it’s even easier to find your way.

Drupal Does Things You Don’t Care About

When you’re under deadline it’s incredibly easy to lose sight of the fact that in most cases, you’re going to be responsible for the care and feeding of the project for a long time. After adding up the perceptions that Drupal is difficult to grok, expensive to customize, and requires special training to operate, many developers and site managers run for their do-it-yourself frameworks and custom solutions.

With that in mind, the fact that the Drupal community is working to add more bizarre-sounding technologies to the mix, perhaps it sounds like more of a liability than a boon. But all technologies were bizarre-sounding before they became important. By the time RSS became an important means of sharing content, Drupal sites had been providing RSS feeds for years. And with well-structured content and nice-looking URLs, Drupal was SEO before SEO was cool. Clear separation between form and content has made it easy and affordable for many Drupal sites to work on phone technologies. When the next important web technology comes to the forefront, do you want to be using it or playing catch-up?

Building on Drupal

Most Drupal mishaps are based on the fact that some of Drupal’s biggest strengths are actually weaknesses. As developers, we’re responsible for the attitude that our clients develop, so it’s important to nurture a positive and forward-thinking attitude. Throughout each project, it helps to set expectations correctly by focusing on the short-term goals, long-term results, and accounting for the needs of everyone involved along the way.

Start with Goals

The biggest mistake any developer or client can make is in making assumptions about what’s possible without enough advance planning or research. Behind every “Drupal mess” is a project where the costs, features, and timeline was established without a clear recognition of the actual steps involved. Avoiding this is a matter of deferring your discussion on technologies, timelines, and tactics until you have taken the opportunity to sit down and have a goal-setting session.

The primary purpose of a goal-setting discussion is to determine what constitutes success. Try to stay away from descriptions of functionality, feature lists, or comparisons with existing sites. Instead, stick to the goals of the stakeholders for the site.

Goals are:

• Clear and descriptive phrases like extend our readership, increases sales, lower our production costs, or even launch in time for the holiday season
• Not functional descriptions such as has a forum
• Measurable through use of statistics, sales numbers, or by other trackable mechanisms
• In priority order. Costs, timelines, and features can be goals, but you should identify the priorities of each, and recognize that you can’t always have everything

Before deciding on the time, scope, and cost trifecta, a developer takes the client’s stated goals and the available resources to produce a doable plan. It’s important to include the developer at the goal-setting phase, not after all of the tactical decisions are made. Because Drupal brings a lot of tools to the table, an experienced Drupal guide can match technology choices with the stated goals. This is much more cost effective than trying to force-fit a requirement into a Drupal site. Best of all, the developer can suggest solutions that sound difficult and expensive but are actually quite simple for Drupal.

Acknowledge and Support Different Participants

Adding a blog to a site is a small technical feat, but generating regular and insightful blog posts can be a full-time job. If your bloggers encounter barriers or feel that they don’t have adequate training and support, they may not feel confident to post new content. If fostering community was the goal you identified during your planning phase, a good Drupal execution may fail to satisfy that goal.

By contrast, the more an author or site owner understands Drupal, the more he can contribute ideas or articulate his needs in a way that works well for Drupal. Functioning is a liaison between people and technology; it’s your job to help people who can contribute content understand where they fit in. Wherever possible, these people should be part of the planning, development, and post-launch strategy:

• Provide some functional demonstrations with real-world projects similar to your client’s site, allowing participants to see how their needs might be translated to Drupal concepts.
• As part of the goal-setting process, consider the input of everyone who may interact with the end result.
• Create a plan that reflects the time and willingness of all participants to work on the project.
• Avoid bottlenecks by ensuring that everyone who needs to contribute can set aside the time and resources required for ongoing participation.
• If appropriate, consider including participants during the implementation process. For example, have a content manager help create new sections as part of an import process, or have content authors practice editing posts before launch.

What if this is overkill? The key to success is not making people take a class they don’t want to be in, it’s understanding what human resources are available and how those resources can be applied to project goals. It’s just as valuable to know that there’s limited time or willingness to participate in discussions, training, and ongoing content management, and there’s nothing wrong with scaling back their involvement as long as that’s not in conflict with stated goals.

Make Sustainable Choices

Along the way we’ve learned that hacking core is bad and that supporting modules with patches and feedback is good. Why spend the extra time? Because sticking to common best practices ensures that the site will work without surprises and that it can be supported by the developer, or any other qualified Drupal developer, for a long time to come.

Custom code and workarounds, while often necessary for quick delivery, add to costs and ultimately draw attention to the fact that the original developer just didn’t know how to complete the project without compromising ongoing maintenance. This is partly why people blame Drupal for being inflexible and expensive to maintain.

Assuming that you are approaching this from a goal-oriented perspective, how do your technology choices affect the stated goals of the project? Perhaps a quick hack can help you launch in time for the holiday season but stymies a Drupal 8 upgrade or raises the cost of maintaining the site in the long run. It’s not always the wrong choice to implement that hack! But by asking your client whether it’s OK to trade short-term work for long-term return on investment, you’re allowing them to help decide which is the most important.

However, before trading ongoing sustainability for short-term results, the first step is to make sure that there really is no better way. Before engaging in hackery, ask via IRC, post a forum question on drupal.org, research what you can by searching for blog posts, or consult with someone who may have more experience in the situation.

There is no reason not to avail ourselves of the abundant resources offered by the Drupal community. Learning how others do things and sharing what we learn along the way is something that helps us all do our jobs better. But bad judgment based on lack of research is useful to nobody.

Understand the Economy of Community

When a feature is missing from a module or Drupal itself, it’s possible for anyone to support the addition of that feature. This often means paying the module maintainer to add it, which is great for Drupal and helps to guarantee that it’s done on your timeline. If that’s not possible, you can also make a lot of progress by providing clear documentation of your request on drupal.org, answering questions in the issue queue and testing patches to free up the maintainer’s time, or contributing code of your own.

This is what makes Drupal amazing, as each small contribution affects an increasingly large group of users. If a module has 100 users, then each fix, feature, or piece of documentation can immediately impact 100 people, and, perhaps, make the module useful to 100 more. The next round of improvements is now exposed to 200 people, further expanding the pool of potential contributors. Drupal is free to download yet extremely powerful because each small effort is expanded exponentially.

Forgetting that these possibilities exist makes it seem that certain things are just broken or missing without any recourse. Browsing the issue queues throughout Drupal.org, it’s common to find questions like, “When will this be ready?” or “Why won’t someone fix this problem?” Ask yourself how you might respond to demands that you work on someone else’s goals and schedule, without any pay, and you realize that complaining is a pretty weak mechanism for getting things done.

Whether you’re expecting to use Drupal to get paid for delivering a project, or planning to rely on a Drupal site to lower costs or increase revenue, it’s a cost-effective investment to support its developers and contribute to a long and healthy future.

Consider Long-term Support and Growth

As cliché as it sounds, a Drupal project launch is not the end of a development project, it’s the beginning of a thriving online resource. Depending on the site’s goals, there may be an active community of users to nurture, features to add, and content managers providing new information and resources. This will fail if nobody knows how to nurture a community, add a feature, or provide new resources.

To a developer who lives and breathes Drupal each day, it’s a disappointing surprise when the client doesn’t just pick the site up and run with it. Including an informal training session as part of the site delivery will help by making the client feel more at home and give them a safe place to ask “dumb” questions. Depending on the skills and requirements of the site contributors, a training session may last a few hours, or even a week or more. Also make sure that you’ve made arrangements for handling questions and additional support as new questions arise.

Ensuring Your Success

Understanding the needs of a Drupal project and approaching it from a goal-oriented perspective are the first steps toward becoming a happy Drupaler, no matter what you choose to do with it. There’s nothing worse than getting caught in a project that is over-budget, over time, or impossible to deliver. Preventing this means setting aside the resources you need to plan carefully and making sure you can get help when you need it.

If you’ve gotten involved in the local or online Drupal community, you’re already halfway there. Approaching each project with the time, thoughtful consideration, and respect for those who have gone before you will help ensure that you’re moving your projects, your career, and possibly even Drupal itself forward.

Create a Process

As a Drupal professional, each project you work on builds on your expertise in harnessing Drupal’s flexibility, community support, and growth for ongoing success. Documenting your findings as a well-defined process provides a repeatable plan of action that you can use to help others find their way as you introduce them to the new mindset.

Some developers define a very rigid process. Before they begin, they develop an immutable feature list and identify specific costs, check-off dates, and milestones. Before a project begins, the client has a clear understanding of exactly what will be included in the project, what it might look like, and how much it will cost. This works well for small projects because it’s predictable for everyone and easier for the client to understand and buy into.

Other developers prefer a more agile process where milestones and check-in meetings are established, and the option to make changes based on new findings is always available. This process works well when there are many participants or other variables that make it difficult to predict the outcome. It’s also possible to deliver a product that’s better than what was imagined at the beginning. This requires a willingness to trade a clear up-front picture for the best possible outcome.

The specifics of your own process are based on how you work best, the nature of your projects, client expectations, and epiphanies you’ve had during your own trial and error. It doesn’t matter how structured or how loose your process is as long as everyone has a clear understanding of expectations—and those expectations are being met.

It’s easy to forget how confusing Drupal is when you’re just starting out, but a documented process can help clients and collaborators feel like they’re on solid ground, engaged in the project, and working with a clear understanding of what’s next. Tips for making this work include:

• Start and end with project goals: Include a goal-oriented planning session at the beginning of the project, and schedule check-ins throughout the project to make sure those goals are reflected. It’s also OK to re-prioritize goals—for example, to defer the launch date for a killer feature—as long as everyone agrees on the new parameters.
• Keep your clients involved: This is deceptively challenging because it’s so easy to assume that clients know what you’re talking about. Make sure there are regular meetings or check-in sessions, and, if the project is large enough, dedicate a project manager to the task of organizing these meetings. Most importantly, ensure that everyone has the proper foundation of knowledge to feel that they can make informed decisions or participate as appropriate.
• Make sustainable choices: When a client requests features or changes, it’s easy to forget what they really need in the interest of chasing what they’re asking for. If they want to make a change that will make it hard to maintain in the future, go back to the stated goals and make sure you’re in alignment. If not, communicate accordingly.
• Build in some community involvement: If you require changes or “hacks,” be sure to file issues on drupal.org so that others may benefit from your findings, and any improvements you make can find their way back into the tools. This raises your Drupal karma and supports ongoing sustainability for tools you depend on.
• Include a post-launch plan: If you don’t want to be on the hook for ongoing support and training, make sure you’re working with someone who can take on this role. If you do plan on sticking around, create a retainer agreement or maintenance plan. Think about how new technologies can benefit their goals, and consider creating a long-term upgrade strategy. Your client will appreciate the forward-thinking attitude.

Adapt and improve as you go. After each project is complete, take some time to make an honest assessment of what worked well and what could be improved next time. Involve your clients if that’s appropriate, and include everyone who worked on developing the project.

Budget Your Time

Many full-time Drupal contractors and development firms find themselves raising their rates significantly after their first few Drupal projects. This doesn’t mean that they’re raking in cash, it means they’re supporting an ongoing commitment to best practices, sustainable choices, and community participation that ensures that they’re staying on the right track. As we’ve learned thus far, this can save a lot of client money and time, so it’s actually a good investment.

This chapter also highlights other time and planning variables, such as communicating what “done” means, working with the community, and coordinating with other participants on the project. The takeaway is that you should leave plenty of room in your development schedule to “measure twice, cut once” and at least doubling the amount of time you predict for a given task.

Include learning time or community involvement time in the estimate, either by setting an hourly rate that allows you to spend less than 40 hours per week on client work or by doubling the time estimates to include these activities directly.

Leverage Existing Resources

In addition to getting your foot in the door, building ties in the Drupal community provides you with a safe environment to ask questions, see how others are doing things, and get help if you need it. There are some additional resources that you can look to when you need an extra hand.

Install Profiles and Distributions

Drupal distributions are a way to hit the ground running with common functionality that lets your new site benefit from the research and hard work of people who already understand the needs of a certain niche audience. To the extent that a distribution is well-supported, its users can also benefit from a user community of like minds, a roadmap for the future, and support resources that pertain specifically to that configuration.

If an install profile is a good fit for the goals of your project, it may be possible to provide something better than expected at a lower cost. You can visit http://drupal.org/project/installation+profiles to begin the process of looking for a profile.

A Little Help from Your Friends

It’s good to have an idea of who you can turn to when things get tricky, so keep some resources in mind from the beginning. It’s often a good idea to keep some experienced developers in mind so that you can consult with them to weigh in on different architecture strategies, recommend modules, or help you avoid potential pitfalls.

Another good source for paid support is in fostering a relationship with the maintainers of the modules or solutions you rely on. Who better to tell you the costs of adding a feature to a module than that module’s author? Supporting the module maintainer also helps to secure the ongoing sustainability of the solution, which means it’s more likely to be supported when you are upgrading to Drupal 8 and beyond.

Working with an experienced developer or strategist may mean budgeting a higher rate for a small portion of the project, but it is usually well worth it. An hour’s worth of insight could save thousands of dollars in workarounds and restructuring.

Building Your Drupal Career

If the rules for planning, developing, and supporting a Drupal site have changed, it’s no surprise that a Drupal developer’s career reflects a new approach. I have painted a picture of how well-managed Drupal projects are structured, highlighting the many roles you might fill throughout the planning, execution, community participation, and ongoing support of a Drupal project.

A successful developer doesn’t need to wear every hat, but she does need to know which roles she can excel at and when to rely on others. This means that you have the freedom to choose to do what makes you happiest and focus on that. It also means that you should be aware that you may need to fill in the gaps from time to time.

Finding Your Place

The first thing is to figure out what “making a living” would look like. If you were happy and successful beyond your wildest dreams, what would you be doing with your time in Drupal? There’s a place for writers, marketers, business analysts, designers, activists, architects, coders, and trainers. Most Drupal sites, even the smallest ones, are more successful when these personalities are involved in both development and long-term maintenance.

Figuring out which roles you want to occupy will help inform your processes and identify where you might seek help and participation. For example:

• If you have a good understanding of business processes or the nuances of a specific industry, you might make a great analyst. Your job would involve developing the goals of a project and making sure that Drupal fits the bill.
• If you’re great at communicating technical concepts, well-organized, and able to keep people motivated, the project manager job title may be in your future. You can help rally the project participants and make sure that everyone has what they need to keep moving ahead.
• If your strength is as a designer, you will want to consider looking for some advanced support or partnership resources with someone who is more technical. This will help you avoid the pitfalls of thinking that something will be easy and then getting caught in a project over your head.
• Similarly, approaching your projects from a more technical background may hinder your capacity to find and work with clients who require more “flair.” If you find a designer you can trust, you can throw yourself into learning as much as you can about the inner workings of Drupal.
• If you’ve got good people skills and want to provide ongoing support, you can consider becoming a trainer or support provider.

It’s also smart to think about the size of projects and the team you’d like to work with. A single Drupal expert can fill every role and launch an impressive site in no time at all. Other projects are on behalf of large organizations with many participants and resources of their own, where each function is managed by an entire department.

If you’re the type of person who wants to have a lot of influence over a project, you might be happiest as an independent contractor or as part of a small team or company. If you thrive on large projects with a lot of complexity, you might find yourself fitting in as part of a larger Drupal team.

Getting Yourself Out There

Whether you’re striking out on your own, on a job hunt, or staying put and ordering “Drupal rockstar” business cards, you’re never on your own. The first order of business is to get involved in the community so that you have a stable foundation. You’ll immediately benefit from the sage advice of people who have been there before you, and you’ll begin to form a network of people you can turn to before things get challenging.

Perhaps the most important aspect of all is that you’ll be putting yourself in front of potential collaborators and employers. Anyone who appreciates the successful outcome of a sustainable, community-oriented development process will be impressed that you’re actively contributing to the Drupal ecosystem.

User Groups and Local Communities

Hopefully by now, you’ve already become part of the community at drupal.org. This is an important way to build your credibility while getting what you need from the community. If you want more hands-on assistance, participating in user groups are a good way to learn from people who want to share a discovery that might help you, or to impress people (and find work) when you have expertise of your own. In addition to training and documentation, user groups are where we all learn about the best practices you’re always hearing about. You can find a local user group for your area by visiting groups.drupal.org and searching for your location or interest.

Community involvement is what you make it. If you’d like to get something different out of a group or community, consider what you can do to improve the resources:

• If the topics are too basic or not covering what you want to learn, suggest meeting topics, sprints, or additional learning groups that fit your needs better. You’ll be sure to attract some like-minded people.
• If you prefer a different format for meetings, suggest an alternative format. In Minnesota, we have three monthly meetings for Drupalers: a general meeting, one for e-commerce topics, and a social happy hour at a local bar. Each of these is organized by a different person, and each attracts a different audience.
• Suggest the group to friends, associates, and other people who might not already know about it. Not everyone will be interested, but it’s good to attract fresh faces and fun to hang out with people you already like.

In all cases, keep your communication open and positive and build on the existing resources. The goal should be to enhance the local community so that it better meets your needs, while still acknowledging the effort that others have invested.

Conferences and Camps

DrupalConis very different from a technical conference where each presentation is a sales pitch from a product representative at a big company. Instead, each session you attend at DrupalCon is presented by the author of a module you depend on, a leader of the community you participate in, or a company who is helping Drupal thrive. This is an important way to keep your finger on the pulse of the Drupal community while you learn about new modules and solutions, find out what’s under the hood of big Drupal sites, optimize your business, and meet new friends and collaborators. In short, it’s extremely valuable to attend a conference and valuable for clients to know that you’re keeping up with technology so they don’t have to.

Meanwhile, the discussions and sprints that take place at DrupalCon define the ongoing direction of Drupal itself, and each attendee can choose whether to watch, learn, or get involved in helping to make positive changes to Drupal and its community. You might attend DrupalCon as a spectator, believing that you have nothing to contribute. All of a sudden, you might find yourself acting on your opinions of how something could be done better. This transition, from spectator to contributor, is how Drupal gets built.

Travel time and conference fees are often prohibitive, but fear not! There’s a growing movement of local “camps” that also offer speakers, working groups, and hands-on learning opportunities. But camps are smaller and local to a particular region. Participating in a camp near your own hometown is a great way to stay in the loop, and you can often get information that’s even more relevant or in-depth than what’s at DrupalCon. Because Drupal is everywhere, you might also have some important module developers in attendance at a local camp.

“Think Drupal, Act Locally”

Don’t forget what Drupal is for in the first place: Connecting people with a message with tools to put that message online. It’s just as important to find a community that surrounds your interests beyond Drupal. For example, communities surrounding:

• Hobbies such as politics, church groups, sporting or outdoors groups, or just about any interest that strikes your fancy.
• Industry or professional focus where you’ve already got passion or experience. This may include non-profit causes, specific industries such as real estate or the arts, or any other professional field.
• Specific technologies that pertain to your specialty, such as graphics, social networking, database and programming technologies, ecommerce, semantic web, or content writing.
• Communities that can directly help your business, such as groups for professionals, unions, co-working facilities, or professional development.

You can find like-minded communities for just about any topic. It’s fun to think about how you might apply Drupal solutions to real-world needs while expanding your professional or personal development. Best of all, you’ll probably shine as the resident Drupal expert! It’s a great way to build confidence and may even lead to your dream job of working with Drupal and a cause that’s close to your heart.

It’s tempting to get yourself over-committed by doing work on a volunteer basis for experience. Remember to treat every project with the same consideration for goal-oriented planning, ongoing involvement, and long-term thinking, especially an unpaid project that can fall off the radar because you can’t sustainably provide the time. Everything you learn about planning, expectations, sustainability, and ongoing involvement is doubly true for volunteer sites.

Out on Your Own: Building a Drupal Business

Perhaps you want to parlay your Drupal chops into a career by striking out on your own and starting a Drupal business, or you may be introducing a Drupal specialty to your existing business. After finding your niche, you’ll want to build a team that can help you keep things running smoothly for you and your clients.

When starting out with small projects, it may seem silly to consider the notion of building a “team” to handle the development and long-term support. One person can often handle every role in a smaller project. But it’s crucial to consider that launching the site is not the end of the project but the beginning of an online Drupal presence. It will always be necessary to consider:

• Who will upgrade the site by adding new functionality or by upgrading the site to a new version?
• Who will provide content administration and long-term content control?
• Who will make sure that the content administrators have the support and training they need?

It’s good to think about all of this before you even begin your first Drupal project. New Drupalers are often surprised when they can’t just deliver on a project and effortlessly move onto the next paying gig. If long-term support is not in your future, consider finding someone to partner with so that you can sustainably take the load off yourself without leaving your clients hanging.

Building a Drupal Career

With so much growth and the need to specialize, now is a great time to be in the Drupal job market. After figuring out where your interests lie, you might begin finding a new Drupal job or working more Drupal into your current job responsibilities.

If you’re working as one of a few Drupal developers on your company’s staff, many of your job demands are the same as those of an independent contractor. You don’t have to take on all of the responsibilities associated with running a business, but as the onsite Drupal guru, you may find yourself answering for the ways that Drupal does things differently. This puts you in the role of resetting assumptions, establishing goals, creating a plan, and involving people throughout the process. Make sure that you’ve got the time, resources, and support of your company to make informed and sustainable choices. Doing things correctly and in a way that works well for the long haul can help make you an office hero.

Alternatively, you might be looking at working as a small part of a large Drupal team, perhaps as part of a development and consulting team. Some of these companies prioritize sustainability, community, and good process, while others just want to crank out a lot of work. Part of your decision to work there will be based on whether they want to work the way you want to work, so be sure to ask about their process and decide where you fit in.

Building Drupal: Making a Living as a Contributor

The more we work with Drupal, the more we find ways that it could be better. Each new user brings a new perspective, a breadth of experience, and a new approach to solving problems they encounter along the way. The difference between a Drupal consumer and a Drupal contributor is nothing more than a willingness to share these insights, strategies, and solutions with the community at large. Sometimes a worthwhile contribution is nothing more than an insightful comment at a user group meeting. Sometimes it’s a substantial rewrite to a key part of Drupal. Large or small, each change is a permanent thread in the fabric of Drupal and its community.

Contributing in this way is a rewarding way to help yourself while helping others. By solving your own problems in a public way, you gain access to new insights from people with common goals. All the while, you’re building your reputation, providing ongoing sustainability for your clients, and participating in the process of making Drupal more viable to more people.

As rewarding as it is, the primary reason for not contributing in this way is lack of resources. Some developers have found a way to form a business model. The more we can support and identify these models, the better off we’ll all be.

Benefits of “Giving Back”

The words “giving back” carry the connotation of altruism and volunteerism. It seems pretty generous to take something you’ve earned money to build, or could have earned money to build, and just give it away for free. In fact, that’s a pretty silly business model: it’s not sustainable to “give” something that has value, so referring to it that way disregards a real business case.

Doing What You Need to Do—but Better

Before skipping to the “giving away” part of the equation, think about why you might write a module in the first place. Generally, your motive is to satisfy a specific goal; whether it’s performing a task more efficiently, connecting through a social network, increasing the participation of the community, or just staying online while your traffic soars. In short, your goal is not to give something away, the goal is to make something better for yourself.

Software is uniquely beautiful because once you give it away, you still have it for yourself. You don’t usually benefit from hording the results of the effort you’ve expended to solve your own problem. After all, there’s no proprietary benefit to dealing with traffic, but if someone else with the same needs can provide feedback on their own experiences, you can benefit from their insights as much as they can benefit from yours.

Participating in a Dialog

Some broader efforts, such as usability, media handling, contact management, or integrating with remote systems, require a lot of effort. When Drupal handles these things properly, it’s a big win that attracts more users and will certainly help expand your business. But accomplishing any of these far-reaching efforts takes a pretty big team, which you may not have at your disposal.

The more you are able to communicate, participate, and drive an initiative that’s near to your heart, the more you’ll be able to influence the solutions that affect your business the most. Drupal affords every one of its users to take either an active or a passive role in this process. Each person who takes an active role, no matter how small, gets to influence the future of Drupal to suit their own goals.

Community Karma

In a relatively close-knit community like Drupal, it’s possible to tell who’s contributing and who’s merely consuming. If a module maintainer were to follow a link to the user account attached to a support request, what would she find? A series of issue comments that say nothing more than “subscribe” or meaningful comments and helpful patches? Most maintainers respond more quickly to issues from another contributor because of the possibility that they may get further assistance or contributions from that person—or just out of simple respect.

Notoriety

We all have our vanities, and some contributors “give back” for the sole purpose of being seen giving back. That works too, and having your name on a well-regarded module is a great way to publicly demonstrate your Drupal skills, while attracting clients who understand the value of supporting a contributing Drupal developer.

Sustainability Counts!

If we all started thinking that “giving back” to Drupal was nothing more than a volunteer effort with no tangible benefit, we would have a difficult time prioritizing it over our jobs, families, and other obligations. It would be bankrupt for everyone to assume that Drupal is about “getting stuff for free” and not advancing our own goals forward by using and supporting a platform that will help us continue to advance our goals in the future.

There’s still work to do in this arena, since it’s rare for anyone to directly support a maintainer’s efforts. We typically prioritize our satisfying our own needs and those of our clients, perpetuate the notion that Drupal and its modules ought to be built, fixed, and supported free of charge, and forget to recognize when applying a small amount of resources might serve a long-term goal.

The danger is creating a dependence on volunteerism. Sometimes that means that the most fruitful developers are those who have a lot of free time. For example, if a student writes a really great module during her free time, it doesn’t matter that she did it without any compensation, because she was happy for the learning experience. Because she’s capable of writing such an awesome module, a Drupal firm snaps her up after she graduates.

Her new employer probably wants her to continue working on the awesome module, but they’re tasked with keeping her gainfully employed. As long as nobody is willing to fund them for the module development, they need to keep her working on deliverables for paying gigs. Thus the developer’s day job is filled with client work while her free time is divided between Drupal, family, friends, and other hobbies. A crucial module loses the attention of a great developer, and that’s a big problem for people who rely on that module.

As a community, it’s not practical to forgo functionality provided by this developer’s module, and it’s impolite to write her angry e-mails insisting that she give up her family time to work on it for us. While there may be 50,000 of us depending on this module, there’s currently no mechanism to request the tiny share that we could each contribute directly to sustain development. This will be a problem as long as the majority of Drupal users maintain the expectation that “someone” should fix or update the code completely free of charge.

Potential Business Models

I can paint a pretty bleak picture, but Drupal has managed to thrive over the years. This is because of the sheer leverage afforded by any effort put into Drupal. If one developer or end user invests half of what they might spend on a proprietary solution, they’ll benefit significantly more than if they went with that proprietary solution.

Because of this, there are a number of indirect ways to support Drupal and open source, forming the rationale for contributing developers to help push Drupal forward for their own needs and for the rest of us.

Convincing Your Clients of the Value of Contributing

Most Drupal contributors support themselves through client development. In a most ideal scenario, that client is paying directly for the time that the developer spends on contributed code. This is in the client’s best interest for all of the reasons listed as benefits of “giving back.” Community contributions can make the tools you’ve built for them work better with less investment than having you write something proprietary.

Take, for example, a web site whose goal is to increase sales. The client pays to build a solution that provides product recommendations whenever a visitor makes a keyword search. If you introduce the idea of releasing this feature as a module, the client may express some concern over “giving away the farm,”—or putting their competitive advantage into the hands of competitors, who may use it against them.

But let’s revisit the goals of the site, which are to increase sales, not to become a company that maintains software. If that module is available to others, someone on Drupal.org might suggest a fix that enhances the search algorithm. Another user might uncover and fix a security hole that puts the site’s visitors at risk. The original client benefits from each of these improvements, increasing sales and consumer confidence along the way. When it comes time to upgrade to Drupal 8, there’s help on developing and testing an upgrade path. Thus, the client can continually advance and gain new sales-improving features with far less effort than carrying the development load in-house.

Contrast this with a one-off module that stays proprietary. Security holes and bugs are brushed under the carpet because nobody will see them anyway, and the client is faced with paying the developer for every change and fix. The functionality is now a barrier to growth because the entire cost of its maintenance is borne by that client.

It’s not always easy to make the case for having clients pay you to write open source so that they can give their secrets away, but if you started with a goals-first development process, it’s possible to show a savvy client how to leverage Drupal.org to further his needs.

The “Development Plus” Model

Something that “works well enough” for the client is often cheaper than something that can be contributed and supported. In these cases, it’s difficult or even senseless to try and contribute code to Drupal.org. However, after participating in several projects, a Drupal developer begins to fantasize about projects that would streamline his process, improve upon her clients’ experiences with Drupal, and make it possible to do more with less in overtime. Effectively, this makes the developer the consumer, and she begins contributing code that would “scratch her own itch.”

Before the CCK module existed, it was difficult for users, but relatively simple for coders, to add basic fields to an existing content type. For example, adding a subtitle to an article might have taken less than an hour. But this task became repetitive, and developers began to wish for a more automated means of performing that task. Thus, the CCK module was born.

Getting CCK from a neat idea to a viable solution took thousands of hours of development time. Even the best account manger would have a difficult time convincing a client that they should fund a thousand hours of development to allow users to add fields. Thus CCK was developed out of necessity and of developers’ shared frustration with performing the same task over and over.

After this investment, CCK became a major factor in Drupal’s flexibility and success as a content management system. But nobody would have predicted this, or funded the effort, without a few visionary coders who were willing to invest their time in that solution.

This story could be told many times over, and it is part of the very fabric of the Drupal we know today. In each case, the time spent on contributing to these efforts was volunteered by a developer in her spare time or by a development company that can reap the rewards of long-term improvements to Drupal itself. The takeaway is that we can create a business model by investing our own surplus resources in solutions we believe in, thus making it a more viable resource for ourselves and our future customers.

Develop a Product Offering

Install profiles are a way to begin the process of building a site based on some assumptions about how it will be used or who will be using it. For example, a blog-only install profile allows a blog-only site to get up and running quickly with common configurations for blog posts, comments, and categories.

In theory, it’s possible to take this work, package it up, and provide it as a hosted service for blog sites, hosted with this platform. Tread carefully! In a competitive marketplace, the likelihood is that your install profile can be downloaded and installed more cheaply elsewhere.

The product is not the Drupal installation itself but the prepackaged knowledge, common resources, and support model that surrounds it. Approach a specific demographic that you already know well, or find a subject matter expert who already knows that market. Work to identify common needs and develop solutions that serve those needs. That solution may include an install profile or a hosted service, but the real model is probably training, community events, or developing relationships and tools that are useful to each of its participants.

It’s challenging work to build a business model that competes with proprietary alternatives, but it is a rewarding way to fund new development while guaranteeing that it is useful to its benefactors.

Direct Funding

The business models described thus far paint a model where we must find indirect ways to cover the time we spend on contributing Drupal, but the most “honest” way to pay for the time we spend on open source solutions is to get paid with the express goal of funding our time working on contributions. This is challenging for a variety of reasons, but it’s not impossible.

The best way to do this is to reach out to funders and grant-making organizations. Increasingly, these organizations are seeing the kinds of repetition of resources that frustrate developers. When a foundation provides resources to 100 non-profits and finds out that they’ve only managed to partially implement 100 copies of the same solution, they begin to realize it’s a waste of effort. If they’re able to see this pattern, it’s possible to appeal to them with a funding proposal that outlines the breadth of impact for a common solution that serves many organizations at a time.

It may also be possible to appeal to a project’s user base directly by making them aware of your ability to do work for hire. There’s a strong case to be made for paying a module maintainer to fix something in the module itself, which might be equivalent to the cost of a brute-force workaround, which would otherwise need to be re-worked-around hundreds of times once again.

Setting Expectations

After determining your overall contribution goals and determining which business model might be a good fit for your work, you start to flesh out how much time you can actually spend supporting your work. Are you able to dedicate a few hours per day? A few hours per year? Are your choices strictly financial and you’d be able to make time for contribution work if someone could fund it?

It’s important to include this information on the project page, by setting the “maintenance status” and providing a small description of your status in a README file, on your user profile, or on a module’s description page.

For example, if you worked on a module for a client but have no intention of maintaining it beyond the project’s completion, you should set the module’s status as “seeking co-maintainer” or another status that indicates your intended level of involvement.

Additionally, if you’re available for hire, make sure to include that information on the module’s page and ensure that you’re crediting anyone who has helped you get the functionality where it is. This is a useful way to garner support while recognizing those who have supported you so far.

Getting Better all the Time

Drupal powers hundreds of thousands of sites and provides thousands of developers with rewarding and productive jobs. And it only gets better: There’s a new success story for every well-managed project, which helps other site owners make the jump. And each contribution, small or large, makes it easier for developers to deliver great results with Drupal.

By approaching Drupal with the right mindset, we can meet our goals by equipping the right people to wield control over the right aspects of your project. While tricky at first, Drupal’s ongoing progress is attributed to a long history of light bulbs switching on over users’ heads as they realize the affect they can have on their own message and online community. Stay with it, plan well, and remember what Drupal is for, and you’ll be behind the next Drupal success story.

Every Drupal developer owes her career to its contributors, and every Drupal user has the potential to become the next contributor. By approaching the community with the right mindset, we can contribute to the inertia that’s pushing Drupal to the next level. Just like Drupal 7 and each previous release, Drupal 8 and beyond will be greater than the sum of its parts, better than any one person could conceive of. It’s a great time to be in business with Drupal!