I love working with Drupal. But it has lots of drawbacks. Mainly, that it’s not easy. Even for developers. We often run up against things that just don’t work as expected. So, time is spent figuring out why and how to make it work. We can usually find a way. But it sometimes costs more to find the solution than is reasonable for a specific project. I have found the same thing with WordPress which, of course, runs this blog. They both have limitations. They both have good core platforms and active communities striving to develop, improve, and extend their platforms. To me, there is no going back.I hope I never have to build a site without either one of them supporting me and giving clients extra value in engaging with the world via the Internet.
I wish I were at Drupalcon this week. I’ve attended a couple and they are full of energy, excitement, friendship and learning is fabulous. But I can enjoy some of the event from afar. Here, if you’re interested is the keynote delivered by Drupal’s founder Dries Buytaert. It’s a little a bit about where the project has been. And a lot of about where it is going.
One of the struggles we have within our company is drawing the line between our hosting services and our web site development services. This most often comes up when we come across sites we built 5-6 years ago and suddenly the technology behind them no longer works. For example, we built sites using our own custom systems. Granted they were based in open source technology like PHP and MySQL and they worked back then. But both PHP and MySQL have advanced. And server systems have advanced. But the original scripts have not kept up with those advances.
So, when a customer calls and says “My site is broken”, we have to make a decision. Do we fix the current site to comply with server systems, or do we draw the line and say we can no longer support those scripts (that we built) and the client will have to upgrade? It’s not a clear cut decision, but it’s one that eventually has to lean toward the latter. Most often, though, we band aid sites to keep them lumbering along until the organization can find the resources to bring their enterprise into the 21st century. Given that we started our hosting service because of all the bad practices we ran in to with large commercial hosts, I tend to bend over backwards to accommodate our clients.
I like to keep our hosting services available because we do a good job customizing our servers to make things run fast and smooth for the majority of our clients. And many of our development clients appreciate dealing with a single vendor for both hosting and site development. But sometimes I wonder if the hosting side is more of a drain on our small company and we should take advantage of all the great cloud services out there and let them deal with the hardware and underlying hosting software while we focus on delivering great web sites.
I returned from Drupalcon in San Francisco on Thursday and have spent the last few days catching up with work and life. I’m just starting to sort through all my thoughts on this great conference. First, I wish I could have attended even more sessions. But fortunately, they were all recorded and are already available on archive.org.
This was the largest Drupalcon yet, and much was made of Drupal’s growth and its growing influence on the web. Dries’ keynote has some interesting statistics on that. Overall, there was a sense that Drupal was quickly transforming from one of several content management systems to a major player in enterprise, government and non-profit sectors. It felt good to be a small part of this community.
I came away with plenty of ideas on business processes, module concepts, the transition to the next version of Drupal due out later this year. I plan to write more about these areas in the coming days and weeks.
I subscribe to a number of web development mailing lists, RSS feeds, Twitter streams, and, of course, talk to web development clients all the time. What I have learned, if that’s the term, is that pricing web development projects is way more art than science. There are apples and kumquats. There are formulas and there are “realms”.There are jobs and there are sales pitches.
The bottom line, and that’s what we’re all concerned with, whether client or vendor, is extremely elusive. There are no standards. There are precious few comparables (that’s a real estate term, and even though that market has been around for many decades, the art of comparing one property to another is still very subjective). And those that exist are either secretive in terms of cost, or ridiculous in the eye of the client (either ridiculously high, or once in a while, ridiculously low).
But many organizations hire web developers based on price. And others hire web developers based on the sales pitch, regardless of price. In both cases, the client is often at a loss because one company will offer to do whatever they want at a great price. Another company will offer to do whatever they want at a very high price. But what is a low price and what is a high price? How do clients judge? How do you know that the developer is worth the price?
It’s A Crap Shoot
If you are a client looking for a web developer and you don’t have a referral from at least 2 trusted people, then you need to find a consultant, fast. Otherwise, it’s a crap shoot. You are at the whims of your budget, or your emotional reaction to a sales pitch. Neither are realistic paths to a successful site. I think there is a market for Internet strategists that help plan a web development project for an organization, but does not do the actual work. Since they are not invested in the project and have the client’s best interest at heart they could be more objective in evaluating proposals.
As it is, we seldom even respond to RFPs. They often take a great deal of work, are unrealistic in how the scope and budget are balanced, and often poorly defined. When we have competed for jobs we usually don’t get them. In following up, I learn that most often it’s because our price is too high. But to me, the price I often quote is scarily close to the edge of profitability. On the other hand, I have been learing what a few other developers have charged for failed projects (ones where the client has come to us because what was promised was far less than what was delivered) and I’m shocked to learn what the client was charged.
I’ve been back from D.C. a couple weeks and I am still trying to distill everything I experienced at Drupalcon. With three days of intense sessions, Birds of a Feather gatherings, discussions and keynote speeches I have yet to find a way synthesize everything. In fact, I was so excited by some of the things I learned, I am frustrated by not bing able to implement them. OK, it’s only been 2 weeks, so I should be patient.
Most of the sites we’re working on only use a small fraction of the power that Drupal has to offer. I’ve realized I need to do a better job helping clients expand their vision of what their sites could be. And do so without appearing to try and sell them features. Tricky balance. But I also really want to find more clients that already have that larger vision and want to leverage the Drupal platform to build a communications center, not just a web site delivering content. In the meantime I’m planning a couple of my own sites that will offer some of these features. It was one of my new year resolutions after all.
Three other general impressions I came away with that I hope to write more about later:
The Drupal community is truly something special
Drupal development continues to lead the way in opening its framework
Drupal 7 will have an ever increasing focus on usability and lovely themes
If you’re interested, all the main sessions and the keynotes were videotaped and can be accessed here. I’m watching sessions I couldn’t attend in person, and rewatching others.
