White House deepens its commitment to Open Source

Yesterday, the White House announced a plan to deepen its commitment to open source. Under this plan, new, custom-developed government software must be made available for use across other federal agencies, and a portion of all projects must be made open source and shared with the public. This plan will make it much easier to share best practices, collaborate, and save money across different government departments.

However, there are still some questions to address. In good open source style, the White House is inviting developers to comment on this policy. As the Drupal community we should take advantage and comment on GitHub within the 30-day feedback window.

The White House has a long open source history with Drupal. In October 2009, WhiteHouse.gov relaunched on Drupal and shortly thereafter started to actively contribute back to Drupal -- both were a first in the history of the White House. White House's contributions to Drupal include the "We the People" petitions platform, which was adopted by other governments and organizations around the world.

This week's policy is big news because it will push open source deeper into the roots of the U.S. government, requiring more government agencies to become active open source contributors. We'll be able to solve problems faster and, together, build better software for citizens across the U.S.

I'm excited to see how this plays out in the coming months!

Founder dilution

As founders of startups raise money from investors, their share of the company gets "diluted". This means the percentage of the company they own gets smaller and smaller. Last month a friend asked me the following question: "What do you believe would be a good equity position as a startup founder after a Series A? I don't want to be diluted too much.". This week, another friend who is in the process of raising money asked me if he should accept certain "preferences" from his potential investors in favor of a higher valuation and less dilution.

My answer to both friends was: "Well, euh, it's complex!". Because I get asked about this regularly, I decided to write a blog post about this. In this blog post, I'll discuss the dilutive effect of (1) of multiple rounds of funding, (2) reverse vesting, (3) options pools, (4) pro-rata rights and (5) liquidation preferences.

Raising Series A

Let's assume that we have a company, and that our company raised four rounds of financing the past five years:

Series A Series B Series C Series D
Pre-money valuation $4,000,000 $13,000,000 $40,000,000 $90,000,000
Injected capital $1,300,000 $3,250,000 $7,000,000 $10,000,000
Post-money valuation $5,300,000 $16,250,000 $47,000,000 $100,000,000
Dilution 25% 20% 15% 10%

"Pre-money valuation" refers to a company's valuation before it receives outside financing, while "post-money valuation" refers to the company's value after the capital injection. So, the post-money valuation is the sum of the pre-money valuation plus the capital raised. The pre-money valuation of your company, along with the amount of capital raised will determine the founders' dilution.

If our company raises its first round of funding (Series A) with a pre-money valuation of $4 million and the Series A investors were to commit $1.3M, the company would have a post-money valuation of $5.3 million. In the example, the Series A investors would receive 25% of the company ($1.3 million is 25% of $5.3 million).

Series A
Pre-money valuation $4,000,000
Injected capital $1,300,000
Post-money valuation $5,300,000
Dilution 25%
   
Founders 75%
Series A investors 25%
   
Total 100%

In an earlier blog post, I recommended a specific formula for deciding how much to give up to an investor in each round. For consistency, this post follows that formula. I consider this formula to be an ideal scenario, and recognize that most founders will be in a situation where they have to give up much more, or even be in a situation where they want to give up more. Don't get hung up on the actual numbers used in our example.

Option pool

You would think that in our example, the founders would be left with 75% of the company after raising their Series A. Unfortunately, this is not usually the case; investors will often insist that an "option pool" is created. An option pool is an amount of the startup's common stock reserved for future employees. Investors expect the employee option pool will equal 10%-20% of the company post-investment; they also expect these shares will be set aside from the founders' equity.

Let's say that the Series A investors' term sheets requires a "15% fully diluted post money option pool" to be setup. This means that the investors want 15% of the company, after the financing is closed, to be in an option pool that will be granted to future employees. The "capitalization table" of our company after the Series A would look like this:

Series A
Pre-money valuation $4,000,000
Injected capital $1,300,000
Post-money valuation $5,300,000
Dilution 25%
   
Founders 60%
Series A investors 25%
Employee option pool 15%
   
Total 100%

The bottom line is that instead of owning 75% of the company, the founders will end up owning 60% of the company, and the investors 25%. For the founders, the $1.3 million financing was not 25% dilutive but 40% dilutive.

As an entrepreneur, I think it is flawed to take the option pool out of the founders' equity; the option pool should be carved out after the financing and dilute both the founders and the investors. After all, future employees who are granted options after the financing add value to the post-money valuation of the company. I'll leave that gripe for another blog post but for the purpose of this blog post, the key take-away is that creating an option pool is usually dilutive for the founders and an important part of the negotiation with investors. The option pool size and the pre-money valuation need to be looked at together and can both be negotiated. Investors should price on the basis of a complete team needed to execute on the opportunity. If the founders have done a good job of hiring that team, the pool size should be smaller. If there are still a lot of hires needed to create a full team to execute, then the pool needs to be larger.

Reverse vesting

Stock options provide employees the right to purchase a set amount of shares for a set price in the future. To encourage employees to stick around, they don't gain control over their options for a period of time. This period is known as the "vesting period". Once the options are vested, they can be exercised. When you exercise the stock options, you buy shares in the company, usually at a very low price.

Founders are different from employees because they received their shares when they started the company -- they don't usually have stock options. To make sure that founders stay with the company, investors will set up a "reverse vesting" strategy. This is similar to "stock option vesting" except that it gives investors the right to repurchase shares already owned by the founders. The "vesting period" in this context measures how many shares the company can repurchase from a departing founder. The longer a founder stays with the company, the less stock the company can repurchase if a founder were to leave.

A founder who remains with the startup through the end of a particular vesting period -- typically four years -- will be fully vested and retain all founder's shares. The founder who leaves before the vesting period expires will most likely be diluted as the company repurchases some founder's shares.

Raising Series B

As our company grows and the time comes to raise a Series B, the expectation is that the valuation of our company has increased. Let's assume we used that $1.3 million well, and that the value of the company grew from $5.3 million to $13 million.

If we raise $3,250,000 additional capital in a Series B financing on a pre-money valuation of $13 million, then the series B investors will get 20% of the company. In the Series B, the founders, the employees (option pool), and Series A investors are all diluted. Often the new investors will require that the option pool is increased. Let's say they want the option pool to remain at 15% -- in this case, the founders, employees and Series A investors would suffer additional dilution on top of the 20%. In our example, the total dilution will be a little over 23%. The new capitalization table looks as follows:

Series A Series B
Pre-money valuation $4,000,000 $13,000,000
Injected capital $1,300,000 $3,250,000
Post-money valuation $5,300,000 $16,250,000
Dilution 25% 20%
     
Founders 60% 46%
Series A investors 25% 19%
Series B investors   20%
Employee option pool 15% 15%
     
Total 100% 100%

Pro-rata rights

It's not always as simple though. Investors will usually insist on "pro-rata rights". Pro-rata rights give investors the right to invest in a startup's future rounds and maintain their ownership percentage as the company grows and raises more capital. It is an important tool for early stage investors, as most of their investments fail. Pro-rata rights allow investors to "follow" the investments that are doing well. Their ability to double-down on winners is important to compensate for their losses. I believe it is fair to give early investors pro-rata rights; they are a reward for backing you early. But as I've learned, this is also where things get complicated.

At times, new investors don't want older investors to participate so that they can take more of the round. Usually, the new investors will insist that they put enough money to work so they can own a substantial-enough share of the company to make the investment worth their time and effort. In this case, the new investors will try to force the old investors to give up their pro-rata rights. Other times, the new investors want early investors to demonstrate their confidence in the company by participating in the round, and to show that they are not overpaying. To facilitate the "pro-rata dance" between investors, and to satisfy both the old and new investors, founders are often required to take more dilution and to give up more of their company. For simplicity, I ignored pro-rata rights in our running example, but founders need to be aware of how pro-rata rights can impact dilution in later funding rounds.

Raising Series C and Series D

Our company continues to grow and goes on to raise Series C and Series D:

Series A Series B Series C Series D
Pre-money valuation $4,000,000 $13,000,000 $40,000,000 $90,000,000
Injected capital $1,300,000 $3,250,000 $7,000,000 $10,000,000
Post-money valuation $5,300,000 $16,250,000 $47,000,000 $100,000,000
Dilution 25% 20% 15% 10%
         
Founders 60% 46% 38% 34%
Series A investors 25% 19% 15% 14%
Series B investors   20% 16% 15%
Series C investors     15% 13%
Series D investors       10%
Employee option pool 15% 15% 15% 15%
         
Total 100% 100% 100% 100%

In our example, the founders would end up with 34% of the company after four rounds of financing (assuming no additional option grants for the founders). As mentioned above, I consider that an exceptional outcome for the founders. Most founders will own substantially less at this point. For example, Aaron Levie, founder of Box, owned about 4% of Box when the company made its public offering in 2015. Zendesk founder and CEO Mikkel Svane owned about 8% at its IPO in 2014, and ExactTarget's co-founder owned 3.8% at the time the company filed its S-1.

Liquidation preferences

But there is more -- I warned you it's complex! When investors put money in your company, they will require the company issue them "preferred stock". Investors' preferred stock has various "preferences" over "common stock", owned by founders and employees. One of the most common preferences are "liquidation preferences". A liquidation preference helps investors make sure that they'll be paid before common shareholders when a company is sold, declares bankruptcy, or goes public. This is especially important when the company is being liquidated for less than the amount invested in it.

If our company was to sell for $75 million, you would think that per the table above, the Series D investor would make $7.5 million (10% of $75 million) and the founders would make $25.5 million (34% of $75 million). However, if our Series D investor negotiated a "liquidation preference" equal to their $10 million investment and the company is sold for $75 million, they will be guaranteed their $10 million back. The remaining $65 million would go to the other shareholders. This is called a "1x liquidation, non-participating preference". In the event the company sells for less than the valuation at the time of the investment, the Series D investors will make more than their percentage ownership, and the founders will make less than their percentage ownership. In other words, when your investors have liquidation preferences, your percentage ownership isn't always what it looks like on paper (or in a capitalization table, to be exact).

Sometimes, investors want "participation rights". In the case of "participation rights", the investors would be entitled to the return of their entire investment prior to the distribution of any proceeds to the common stockholders. However, the preferred stockholders would then also be treated like a common stockholder and would share in the remaining proceeds. If our company sells for $75 million, the Series D investors would get their $10 million out first, and then get their 10% share of the remaining $65 million for a total return of $16.5 million ($10 million + 10% of $65 million).

There is also a concept called a "multiple". Where founders and employees can get really hurt is when preferred stock owners have a 2x or 3x multiple. If our Series D investors have "3x liquidation rights, participating", they would be guaranteed $30 million back (3 times $10 million) and take 10% of the remaining $45 million. The founders would make $15.4 million. Instead of their 34% share, the founders only get 20%. So, before you agree to any liquidation multiple or participating rights, you should run a few models to understand how much you and the other founders will receive based on various liquidation scenarios.

Because of the preferences, the price or market value of common stock is typically much smaller than that of preferred shares -- especially in the early days. Because common stock is worth less than preferred stock, your percentage ownership is often meaningless. This is often evidenced either by a 409(a) valuation in the USA, or the market price of common stock when sold to a third-party. Preferences generally expire at an IPO, at which time preferred stock converts into common stock. At that point, common and preferred shares have the same value.

Conclusion

In summary, valuations, multiple rounds of funding, option pools, reverse vesting, pro-rata rights and liquidation preferences can all have a dilutive effects on startup founders. As a founder, it can be difficult to predict or plan how much dilution you will suffer along the way. As with everything, the devil is in the details -- and hopefully this blog post helped you be a bit smarter about raising money and negotiating term sheets. In general, I don't think founders should worry about dilution too much but that is a topic for a future blog post ...

The rise of Drupal in India

Earlier this week I returned from DrupalCon Asia, which took place at IIT Bombay, one of India's premier engineering universities. I wish I could have bottled up all the energy and excitement to take home with me. From dancing on stage, to posing for what felt like a million selfies, to a motorcycle giveaway, this DrupalCon was unlike any I've seen before.

Drupalcon group photo
A little over 1,000 people attended the first DrupalCon in India. For 82% of the attendees, it was their first DrupalCon. There was also much better gender diversity than at other DrupalCons.

The excitement and interest around Drupal has been growing fast since I last visited in 2011. DrupalCamp attendance in both Delhi and Mumbai has exceeded 500 participants. There have also been DrupalCamps held in Hyderabad, Bangalore, Pune, Ahmedabad Jaipur, Srinagar, Kerala and other areas.

Indian Drupal companies like QED42, Axelerant, Srijan and ValueBound have made meaningful contributions to Drupal 8. The reason? Visibility on Drupal.org through the credit system helps them win deals and hire the best talent. ValueBound said it best when I spoke to them: "With our visibility on drupal.org, we no longer have to explain why we are a great place to work and that we are experts in Drupal.".

Also present were the large System Integrators (Wipro, TATA Consultancy Services, CapGemini, Accenture, MindTree, etc). TATA Consultancy Services has 400+ Drupalists in India, well ahead of the others who have between 100 and 200 Drupalists each. Large digital agencies such as Mirum and AKQA also sent people to DrupalCon. They are all expanding their Drupal teams in India to service the needs of growing sales in other offices around the world. The biggest challenge across the board? Finding Drupal talent. I was told that TATA Consultancy Services allows many of its developers to contribute back to Drupal, which is why they have been able to hire faster. More evidence that the credit system is working in India.

The government is quickly adopting Drupal. MyGov.in is one of many great examples; this portal was established by India's central government to promote citizen participation in government affairs. The site reached nearly two million registered users in less than a year. The government's shifting attitude toward open source is a big deal because historically, the Indian government has pushed back against open source because large organizations like Microsoft were funding many of the educational programs in India. The tide changed in 2015 when the Indian government announced that open source software should be preferred over proprietary software for all e-government projects. Needless to say, this is great news for Drupal.

Another initiative that stood out was the Drupal Campus Ambassador Program. The aim of this program is to appoint Drupal ambassadors in every university in India to introduce more students to Drupal and help them with their job search. It is early days for the program, but I recommend we pay attention to it, and consider scaling it out globally if successful.

Last but not least there was FOSSEE (Free and Open Source Software for Education), a government-funded program that promotes open source software in academic institutions, along with its sister project, Spoken Tutorial. To date, 2,500 colleges participate in the program and more than 1 million students have been trained on open source software. With the spoken part of their videos translated into 22 local languages, students gain the ability to self-study and foster their education outside of the classroom. I was excited to hear that FOSSEE plans to add a Spoken Tutorial series on Drupal course to its offerings. There is a strong demand for affordable Drupal training and certifications throughout India's technical colleges, so the idea of encouraging millions of Indian students to take a free Drupal course is very exciting -- even if only 1% of them decides to contribute back this could be a total game changer.

Open source makes a lot of sense for India's thriving tech community. It is difficult to grasp the size of the opportunity for Drupal in India and how fast its adoption has been growing. I have a feeling I will be back in India more than once to help support this growing commitment to Drupal and open source.

A history of JavaScript across the stack

Did you know that JavaScript was created in 10 days? In May 1995, Brendan Eich wrote the first version of JavaScript in 10 days while working at Netscape.

For the first 10 years of JavaScript's life, professional programmers denigrated JavaScript because its target audience consisted of "amateurs". That changed in 2004 with the launch of Gmail. Gmail was the first popular web application that really showed off what was possible with client-side JavaScript. Competing e-mail services such as Yahoo! Mail and Hotmail featured extremely slow interfaces that used server-side rendering almost exclusively, with almost every action by the user requiring the server to reload the entire web page. Gmail began to work around these limitations by using XMLHttpRequest for asynchronous data retrieval from the server. Gmail's use of JavaScript caught the attention of developers around the world. Today, Gmail is the classic example of a single-page JavaScript app; it can respond immediately to user interactions and no longer needs to make roundtrips to the server just to render a new page.

A year later in 2005, Google launched Google Maps, which used the same technology as Gmail to transform online maps into an interactive experience. With Google Maps, Google was also the first large company to offer a JavaScript API for one of their services allowing developers to integrate Google Maps into their websites.

Google's XMLHttpRequest approach in Gmail and Google Maps ultimately came to be called Ajax (originally "Asynchronous JavaScript and XML"). Ajax described a set of technologies, of which JavaScript was the backbone, used to create web applications where data can be loaded in the background, avoiding the need for full page refreshes. This resulted in a renaissance period of JavaScript usage spearheaded by open source libraries and the communities that formed around them, with libraries such as Prototype, jQuery, Dojo and Mootools. (We added jQuery to Drupal core as early as 2006.)

In 2008, Google launched Chrome with a faster JavaScript engine called V8. The release announcement read: "We also built a more powerful JavaScript engine, V8, to power the next generation of web applications that aren't even possible in today's browsers.". At the launch, V8 improved JavaScript performance by 10x over Internet Explorer by compiling JavaScript code to native machine code before executing it. This caught my attention because I had recently finished my PhD thesis on the topic of JIT compilation. More importantly, this marked the beginning of different browsers competing on JavaScript performance, which helped drive JavaScript's adoption.

In 2010, Twitter made a move unprecedented in JavaScript's history. For the Twitter.com redesign in 2010, they began implementing a new architecture where substantial amounts of server-side code and client-side code were built almost entirely in JavaScript. On the server side, they built an API server that offered a single set of endpoints for their desktop website, their mobile website, their native apps for iPhone, iPad, and Android, and every third-party application. As a result, they moved much of the UI rendering and corresponding logic to the user's browser. A JavaScript-based client fetches the data from the API server and renders the Twitter.com experience.

Unfortunately, the redesign caused severe performance problems, particularly on mobile devices. Lots of JavaScript had to be downloaded, parsed and executed by the user's browser before anything of substance was visible. The "time to first interaction" was poor. Twitter's new architecture broke new ground by offering a number of advantages over a more traditional approach, but it lacked support for various optimizations available only on the server.

Twitter suffered from these performance problems for almost two years. Finally in 2012, Twitter reversed course by passing more of the rendering back to the server. The revised architecture renders the initial pages on the server, but asynchronously bootstraps a new modular JavaScript application to provide the fully-featured interactive experience their users expect. The user's browser runs no JavaScript at all until after the initial content, rendered on the server, is visible. By using server-side rendering, the client-side JavaScript could be minimized; fewer lines of code meant a smaller payload to send over the wire and less code to parse and execute. This new hybrid architecture reduced Twitter's page load time by 80%!

In 2013, Airbnb was the first to use Node.js to provide isomorphic (also called universal or simply shared) JavaScript. In the Node.js approach, the same framework is identically executed on the server side and client side. On the server side, it provides an initial render of the page, and data could be provided through Node.js or through REST API calls. On the client side, the framework binds to DOM elements, "rehydrates" (updates the initial server-side render provided by Node.js) the HTML, and makes asynchronous REST API calls whenever updated data is needed.

The biggest advantage Airbnb's JavaScript isomorphism had over Twitter's approach is the notion of a completely reusable rendering system. Because the client-side framework is executed the same way on both server and client, rendering becomes much more manageable and debuggable in that the primary distinction between the server-side and client-side renders is not the language or templating system used, but rather what data is provisioned by the server and how.

Universal Javascript
In a universal JavaScript approach utilizing shared rendering, Node.js executes a framework (in this case Angular), which then renders an initial application state in HTML. This initial state is passed to the client side, which also loads the framework to provide further client-side rendering that is necessary, particularly to “rehydrate” or update the server-side render.

From a prototype written in 10 days to being used across the stack by some of the largest websites in the world, long gone are the days of clunky browser implementations whose APIs changed depending on whether you were using Netscape or Internet Explorer. It took JavaScript 20 years, but it is finally considered an equal partner to traditional, well-established server-side languages.

When traffic skyrockets your site shouldn't go down

This week's Grammy Awards is one of the best examples of the high traffic events websites that Acquia is so well known for. This marks the fourth time we hosted the Grammys' website. We saw close to 5 million unique visitors requesting nearly 20 million pages on the day of the awards and the day after. From television's Emmys to Superbowl advertisers' sites, Acquia has earned its reputation for keeping their Drupal sites humming during the most crushing peaks of traffic.

These "super spikes" aren't always fun. For the developers building these sites to the producers updating each site during the event, nothing compares to the sinking feeling when a site fails when it is needed the most. During the recent Superbowl, one half-time performer lost her website (not on Drupal), giving fans the dreaded 503 Service Unavailable error message. According to CMSWire: "Her website was down well past midnight for those who wanted to try and score tickets for her tour, announced just after her halftime show performance". Yet for Bruno Mars' fans, his Acquia-based Drupal site kept rolling even as millions flooded his site during the half-time performance.

For the Grammys, we can plan ahead and expand their infrastructure prior to the event. This is easy thanks to Acquia Cloud's elastic platform capacity. Our technical account managers and support teams work with the producers at the Grammys to make sure the right infrastructure and configuration is in place. Specifically, we simulate award night traffic as best we can, and use load testing to prepare the infrastructure accordingly. If needed, we add additional server capacity during the event itself. Just prior to the event, Acquia takes a 360 degree look at the site to ensure that all of the stakeholders are aligned, whether internal to Acquia or external at a partner. We have technical staff on site during the event, and remote teams that provide around the clock coverage before and after the event.

Few people know what goes on behind the scenes during these super spikes, but the biggest source of pride is that our work is often invisible; our job well done means that our customer's best day, didn't turn into their worst day.

Pages

Dries Buytaert is the original creator and project lead of Drupal and the co-founder and CTO of Acquia. He writes about Drupal, startups, business, photography and building the world we want to exist in.

Updates from Dries straight to your mailbox