Dries Buytaert

At Acquia, we spent a lot of time improving the Webform module, one of the top 10 most popular Drupal modules, as well as the Form Builder module, a companion module that provides an improved user interface for the Webform module. The Webform module and the Form Builder module allow people to create custom forms such as contact forms, online surveys and more.

Both modules are maintained by Nate 'quicksketch' Haug, one of the top Drupal contributors. Like anything Nate does, the modules are amazingly powerful and have great code quality. We wanted to add support for creating custom forms to Drupal Gardens and believed that the Webform and Form Builder modules were the right way to go. No need to reinvent the wheel.

Before making Webform and Form Builder available as part of Drupal Gardens, we wanted to try and see if we could make Webforms easier to use, without making it less powerful. We spent about 200 hours to explore various different design and interaction models. We used both paper prototypes and working prototypes to conduct usability tests, and used these to drive further optimizations. After we felt good about the direction, we ran it by quicksketch. With quicksketch's guidance, we helped upgrade both modules from Drupal 6 to Drupal 7, and implemented the new user interface on top of that. The new drag-and-drop interface puts some things in different locations on the page and has a number of different interaction patterns compared to the old user interface. To do so, we wrote a couple of modules that add our user interface on top of the Webform and Form Builder modules. It is layered like a stack: Webform → Form Builder → Alternate UI.

Fast forward 25 person-weeks, and we've now rolled out our improved user interface as part of the latest Drupal Gardens release. To see how it looks, take a look at the video below or create a free Drupal Gardens website if you prefer.

We're contributing everything back to the community -- some things we've already contributed back, other things we're in the process to. We're also helping to back port some changes to Drupal 6, even though we don't need them for Drupal Gardens. With these contributions, everyone in the community can benefit.

The new user interface is an incredible achievement that a lot of people deserve recognition for, including quicksketch who spent many years of getting Webform and Form Builder modules to where we were able to use them as a starting point.

I'm pretty excited about this user interface, and would love your feedback and suggestions. What do you think?

Update on January 10th, 2011: the Webform Alternate UI module is now available on drupal.org. This module provides an alternate user interface for the Webform module, allowing you to create and edit forms from within an easy-to-use form building tool.

I recently had the pleasure of serving as a thesis advisor on a work by Marc Seeger, who was completing a portion of his requirements for a Master of Science in Computer Science and Media at Stuttgart Media University. Marc's thesis was titled "Building blocks of a scalable web crawler".

Marc undertook a project for Acquia that I had originally started in 2006; a Drupal site crawler to catalog, as best as possible, the current distribution of Drupal sites across the web. That is a task for which there is no easy answer as Drupal can be downloaded and used free (in all senses of the word). The best way to find out how many Drupal sites exist, is to develop a crawler that crawls the entire web and that counts all the Drupal sites one by one.

With Marc's help, I was able to resurrect my crawler project. Marc spent 6 months working with me; 3 months were spent in Germany where Marc lives, and 3 months were spent in Boston where Acquia is based.

During that time, Marc explored suitable architectures for building out, collecting and managing website data on the order of many millions of domains. He examined different backend storage systems (Riak, Cassandra, MongoDB, Redis, CouchDB, Tokyo Cabinet, MySQL, Postgres, ...), contemplated the methods of collecting the data while simultaneously allowing search and access. As part of his work, Marc explored a variety of different database technologies, database schemas and configurations, and experimented with various configurations of Amazon's Elastic Cloud hardware (EC2). Issues common to any large deployment were investigated and analyzed in detail, including HTTP persistent connections, data locking and concurrency control, caching, and performant solutions for large-scale searches. HTTP redirects, DNS issues -- his thesis covers it all, at least in terms of how each of these items impacted the search for an acceptable algorithm.

The crawler has been up and running for a number of months now, and investigated about 100 million domain names. Now we crawled about 100 million domain names, I plan to start publishing the results.

Marc's work is available in PDF from his blog post, and it's a good read, even if I'm slightly biased. Thanks for the great work, Marc! Time to look for a couple new thesis projects, and thesis students that want to work with me for a few months. Ideas welcome!

During the past month, I've been trying New Relic on my personal blog. New Relic is a performance management tool. It can help to monitor, debug and optimize a site. It includes features like slow page request analysis, slow database query analysis, error tracking, scalability analysis, performance alerts, weekly e-mail reports, up-time monitoring and even very specialized features like Apache Solr profiling. It's a bundle of developer goodies that can be used on live production websites.

I'm a bit of a profiling geek. In my previous life, I spent a lot of time working on production profiling and performance optimization of Java applications. So when New Relic recently announced that they're working on support for PHP applications, I wanted to give it a try.

We began testing New Relic when the PHP version was still in beta. We believe it can make for a great service to add to Acquia Hosting and the Acquia Network. My site is hosted on Acquia Hosting which is why I have been testing it on my site. So far the testing has been good. We've helped New Relic fix a number of bugs during the beta test period, and in return New Relic has helped us to discover a performance problem in one of our deployment scripts on Acquia Hosting. Proof that New Relic is useful!

Now that we are past internal testing, I am excited to say that we will soon be bundling New Relic into the Acquia Network. Every Acquia customer will soon get access to a premium version of New Relic's monitoring tools at no additional charge -- whether you are hosting with us or not. Expect more detail from us soon on how to access New Relic as a subscriber.

New Relic requires a small 'agent' to be installed on your web server. The agent hooks into the PHP interpreter and sends the relevant information to a back-end for analysis and visualization. Because it hooks into the PHP interpreter, it can provide that deep, code-level visibility that is useful when debugging a performance problem. The New Relic agent also adds extra Drupal specific instrumentation -- and will probably add more over time.

I've only used it on my personal site, which currently runs on a regular Drupal 6. However, I'm quite keen to unleash it on a Drupal 7 installation to see what we can learn. In the mean time, I'm including some screenshots of what my personal blog looks like according to New Relic. If you're interested in improving the performance of your site and are a profiling geek like me, you should give New Relic a try.

New Relic uses <a href="http://en.wikipedia.org/wiki/Apdex">Apdex</a>, an industry standard for measuring the satisfaction of a user of an application or service.

New Relic conveniently separates database performance from PHP performance. On a busy system, that makes it easy to pinpoint bottlenecks.

New Relic tries to annotate performance problems to 'controllers' rather than to specific URLs. Thus, it automatically extracts 'Drupal page callbacks'. This is nice because when an application has thousands of unique URLs (<code>/article/11/19/why-mysql-is-cool</code> and <code>/article/11/19/postgres-is-cool</code> and so on) that are all handled by the same controller (e.g. <code>node_page_view()</code>).

This graph shows that most of my database time is spent reading and writing to the <code>accesslog</code> MySQL table. By disabling the access log feature in Drupal, I could reduce my database load roughly in half.

Things are heating up in the Drupal world as both CommerceGuys and SubHub raised venture capital money. We're still waiting for an official announcement, but word on the street is that CommerceGuys raised around 1 million euros to develop a number of e-commerce products and services for Drupal. SubHub raised more than 1.2 million euros to date to develop SubHubLite, a hosted service for Drupal 7 comparable to Drupal Gardens and Buzzr. In addition to CommerceGuys and SubHub, I know of at least two other Drupal companies that are in the process of raising money from investors ...

Selling a product has more upside potential than selling consulting and professional services which you can only bill by the hour. However, it is difficult to bootstrap a product based business without a major investment of funds -- usually from outside investors. I've seen many try and fail. In almost all cases, it failed because the company was under-capitalized. It takes a lot of resources to create a successful and defensible product. Furthermore, people tend to forget about sales and marketing. It's not enough to build your product -- you have to bring it to market as well. That is not trivial either.

I know bootstrapping is hard because I'm bootstrapping Mollom. I know building a product is hard because every day at Acquia, I see how much time and effort goes into our different products.

I don't have a rich uncle, so I would not have been able to co-found Acquia without venture capital financing. We decided that we wanted to focus on being a support and software product company with a strong partner eco-system. Starting Acquia wasn't the easiest route for me, but looking back at the past three years of Acquia, I believe that I made the right decision. Based on how much Acquia has contributed to Drupal and what it has enabled me to do, I like to believe it would have been a loss if I had taken a more conventional route -- or had I decided to continue to work on Drupal as a hobby project.

It's refreshing to see that more and more Drupal companies aspire to become successful product companies and that they are seeking venture capital. I always admired the Ruby on Rails community for its seemingly entrepreneurial attitude. I'm glad to see more of it in the Drupal community as well. There is a good deal of fear surrounding venture capitalists but if Drupal is going to grow, we should expect to see more venture-backed companies building Drupal products. Venture capital financing can be good, especially if these companies give back to Drupal and if they build products and services that make our life easier. We all benefit from that.

In this post, I want to focus on one of the most difficult questions for entrepreneurs raising money from investors: what is the right amount of capital to raise? We debated this question extensively in each of the three rounds of raising venture capital at Acquia. It's particularly a tricky question for people like me who are relatively new to venture capital. I spent plenty of time thinking about this and talked about it with numerous successful entrepreneurs that have raised money before.

Based on my own thoughts and my informal survey, my current best answer is the following: the right amount of money to raise is somewhere between the following two choices: (1) enough to build the business that you want to build and (2) as much as you can without being insane or irresponsible. Unless the company does incredibly well, the difference won't be that large.

Raising less money than you actually need can be really destructive. First, it could cause you to miss opportunities because you won't be able to expand fast enough. Second, the company might not survive unexpected setbacks. Last but not least, without sufficient capital you might not be able to attract or retain the right talent you'll need.

Conversely, raising too much money unnecessarily dilutes the ownership of both the founders and the employees. It also makes it difficult to raise more money later on. And it makes it harder to sell the company: the more money you raised, the bigger the price tag becomes as the investors will look to make a multiple on their investment. At a minimum (worst case), you will have to sell the company for at least the total liquidation preference -- hopefully a 1x non-participating.

When in doubt, raise more money rather than less. Growing a start-up is hard as it is. You don't want to introduce more risk by not having enough capital. You want to be able to run a few experiments, make a few mistakes or be able to take advantage of unexpected opportunities.

Being able to project how much cash you'll need is an important discipline to master. Cash is the lifeblood of any company. Making financial projections and forecasts is obviously more difficult when the company is pre-revenue or just starting to take in revenue. You'll have to make many assumptions.

Trying to determine how much money you need feels like trying to solve an equation with too many unknowns. It's a balance between the size of the opportunity, increasing the likelihood of success, optimizing for the financial outcome of all employees, the business' situation relative to the market, and so forth.

At Acquia, we made assumptions about the number of customers, average sale price, customer acquisition cost, product mix, etc. We used these assumptions to estimate our costs and revenues. To help ensure that we weren't fooling ourselves, we tried to validate as many of our assumptions by talking to other entrepreneurs and comparable companies. So we talked to key people from other open source companies (e.g., MySQL and jBoss) that are in the commercial support business.

The better your assumptions, the better you can estimate how much capital it takes to build your company. In each of our funding rounds, we raised at least enough money to achieve our goals and some extra beyond our plans to handle bad surprises or unexpected opportunities. So far, that has been a good strategy for us.

Movember has come to an end, and soon I will remove the moustache that I groomed so carefully during the month of November. Before I shave, though, I want to thank everyone who sponsored my moustache.

The Acquia team, of which I am a part, raised a whopping $23,500 USD, and donations are still coming in. That puts us in the top 25 teams nationally. When we first started talking about doing a Movember campaign at Acquia, no one would have thought we'd have the impact that we did since we conducted the program with a relatively small team. I continue to be amazed by what this team can do when we put our minds together to achieve something.

Myself, I raised a total of $699 for the team. When I wrote my Movember announcement post, I jokingly said that I'd humiliate myself publicly by posting pictures when I raised more than $500. While some people gave me money not to post any pictures, or to shave prematurely, I still owe it to many others to show the result of my mo' growing efforts. Pictures or it didn't happen.

Of course, the real "thank you" should go to the many people that donated money to our cause. Thanks to them a significant amount of money will go to cancer awareness and research. Thank you!

To my surprise, a lot of people that I interview at Acquia don’t understand stock options or have never heard of it. This blog post explains what stock options are about. It is a very technical topic but for the sake of this post, I am going to keep it really simple and make some over-simplifications.

In essence, a stock option is a right given to an employee to purchase stock at some point in the future at a set price.

When a company is founded, the founders own 100% of the company. When they raise money from investors, they give them a share of the company's stock in exchange for money. In addition to that, most institutional investors will require that you establish an "option pool" which usually accounts for 10% of the company. So if you sold 30% of your company to an investor for 2 million dollars, and you set aside 10% for the option pool, the founders still own 60% of the stock and have 2 million dollars to work with.

Having an option pool is very common for a venture backed startup, and fairly uncommon for most small companies. At Acquia, which is a venture backed company, we give our full-time employees stock options on top of a competitive salary. These options come from our option pool.

If you are an employee of a startup, stock options are a big deal as you are going to receive stock options as part of your compensation. It is a big deal because it means you have the option to be a shareholder and to share in the gains. It's a big part of the startup culture, and an important reason why top engineers prefer venture backed startups.

So what exactly does that mean for you as an employee?

When you join a startup as an employee, in addition to your salary, you might be granted 10,000 stock options at a strike price of $1 per share. Those options are taken from the stock option pool that is set aside especially for employees. In our example above, all employees together can own up to 10% of the company.

When the company is founded, the stock is basically worthless. The founders, the employees and the investors will want to steadily increase the value of the company, and by extension, the value of the company's stock.

At the time of an exit, the stock is hopefully worth $100 per share or more. So if you were granted 10,000 options at a strike price of $1 per share, you can buy 10,000 shares for $10,000. However, at that point, the shares are immediately worth $1,000,000 as over the years, the stock price has increased to $100 per share. In other words, the 10,000 shares that you got when you joined, can make you a $990,000 profit on top of your salary.

Granted, the value of the company might not always go up, or it might not go up that fast, but it certainly could. Hundreds of Google employees became millionaires overnight when Google went public. Hundreds of Google employees left to join Facebook -- not because they get a better salary but to get some of Facebook's pre-IPO stock options. When a startup is growing and successful, the price will go up over time. At the same time, if the company fails, the employee equity will be worthless.

The reason startups use stock options is because it allows them to attract and retain high-quality people at reasonable salaries. You can choose to go work for a startup for $85,000 per year in salary and 10,000 stock options granted over 4 years, or you can choose to work for a company for $90,000 in salary and get no stock options at all.

Do you want to take the reduced salary and some risk and swing for the fences, or you do you prefer predictability without the potential for a big upside?

My first job out of college I worked for a venture backed startup that granted me two rounds of stock options -- both grants were rendered worthless as the company didn't survive the bubble in 2001. Even so, I never regretted the choice to go work for this startup. I still got paid a fair salary, I learned a lot and just loved the start-up culture that we had created.

I firmly believe there is an entrepreneur tucked away in many of the best people. For those people, the daily satisfaction of working with high-quality colleagues in a fast-growing company, and the ability to share in the company's success as a shareholder, is worth a lot more than a bigger salary and predictability. I knew that was true for me when I was 21, and I know it is still true now that I'm 31.