Hiking the Great Wall

Last weekend I had the opportunity to visit the Great Wall of China, the world's longest wall at 8,850 kilometers (5,500 miles). The Great Wall runs mostly through the mountains to take advantage of natural obstacles. As a result, it was quite the hike to get there but once on the Great Wall, the scenery was beyond sensational. It runs like a relentless serpentine over the horizon, evoking the image of a giant dragon.

Great wall

I learned that the Great Wall is actually a discontinuous network of walls built by various dynasties. The Chinese started building the Great Wall as early as the 7th century BC and kept building for over 2,000 years!

Great wall

It is said that over one million people died building the Great Wall. Every step you take, you can't stop imagining how they built it and the many people who suffered. I was pretty much alone on the wall, so it was not hard to imagine the lonesome life of a Ming soldier up here, waiting for something to happen. The history, the scenery, the peacefulness -- it just made me speechless.

Great wall

The end of ownership: the zero-marginal-cost economy

Society is undergoing tremendous change right now -- those of us who enjoy services like Uber and Kickstarter are experiencing it firsthand. The sharing and collaboration practices of the internet are extending to transportation (Uber), hotels (Airbnb), financing (Kickstarter, LendingClub), music services (Spotify) and even software development (Linux, Drupal). While the consumer "sharing economy" gives us a taste of what it's like to live in a world where we own less, perhaps there is an equally powerful message for the business community. Using collaboration, companies are dramatically reducing the production cost of their goods or services.

Welcome to the zero-marginal-cost economy, a way of doing business where ownership of a core process is surrendered to community collaboration. In economic terms, the cost of a product or a "good" can be divided into two parts. The first part is a "setup cost", which is the cost of assembling the team and tools needed to make the first unit. The second part is called the "marginal cost", or the cost of producing a single, additional unit.

For decades, competitive markets have focused on driving productivity up and marginal costs down, enabling businesses to reduce the price of their goods and services to compete against each other and win customers. A good example of this approach is Toyota, which completely reinvented how cars were made through lean manufacturing, changing the entire automotive industry. Japanese cars were produced much more quickly than their American counterparts, created via traditional assembly lines in Detroit, ultimately driving down the final cost for consumers and shrinking margins for companies like Ford. Software development methodologies like the lean startup methodology and Kanban are modeled after the Toyota production line and have made software development more efficient.

Today, the focus is changing. Within service industries like hospitality and transportation, new entrants are succeeding not by optimizing production, but by eliminating production cost altogether. Consider Uber versus traditional taxi companies. For a traditional taxi company to add another taxi to its fleet, a car and license need to be acquired at significant cost. Instead of shouldering that setup cost, Uber can add another taxi to its inventory at almost no cost by enabling people to share their existing cars, all coordinated via the internet. Airbnb does the same for renting properties vs. acquiring more physical space. The fact that both these companies have near zero-marginal-cost production is threatening longstanding business and regulatory models alike.

In the software industry, the low marginal cost of producing Open Source Software threatens to our equivalent of longstanding business models: proprietary software companies. Free Open Source Software essentially can undermine the way proprietary software companies make money -- by selling software licenses. By sharing the cost to develop software, organizations can increase their productivity, accelerate innovation and bring down their setup costs.

The open source ideology extends even further beyond software. Last month, Elon Musk open sourced the patents for Tesla. His main reason? Pushing the automotive industry to create more electric cars. If Elon Musk is an indicator for industries across the board, it's further proof that capitalism is starting to become more collaborative rather than centered around individual ownership.

Great businesses can be built by adding value on top of a low-marginal-cost community that is owned by many. For example, my company, Acquia, creates value on top of the open-source Drupal software by providing support and software-as-a-service tools. Similarly, Uber adds value by providing consumer-friendly, on-demand services beyond just increasing the supply of available cars on the road. In both cases, the companies' products grow stronger as their communities grow, even as the acceleration of those same communities brings down marginal costs. The power of the community vastly improves previously inefficient base process (such as waterfall software development or taxi regulations) and creates a forcing function for business to generate profit based on products and services that appeal directly to users.

Within the next decade, businesses will need to become much more open and collaborative to survive in an increasingly zero-marginal-cost economy. Those who develop proprietary software are finding it harder and harder to sustain "business as usual". The sharing economy and collaborative development will further streamline capitalism, and organizations that figure out how to master this dynamic will succeed. A community model can work in any number of industries -- we just have to challenge ourselves to as entrepreneurs to discover how.

(I originally wrote this blog post as a guest article for The Next Web. I'm cross-posting it to my blog.)

Visiting China and Japan

After spending the summer in Boston, I'm ready to fly across the world ... literally, as I'm leaving on a two week trip to China and Japan later this week. I'm very excited about it as I've never had the opportunity to see either of these countries.

I will arrive in Beijing on Saturday, September 6th, for the Young Global Leaders Annual Summit. A private path from where I'll be staying leads to a non-restored section of the epic Great Wall of China. Exploring this truly untouched piece of Chinese history still in its original landscape should be a special experience! Stay tuned for photos.

Following my time in Beijing, I'll transfer to Tianjin to attend Summer Davos. In addition to that, we're organizing a meetup with the local Drupal community - https://groups.drupal.org/node/434658. If you are in the area on September 10th, please stop by for a drink. I'd love to meet you and learn about the state of Drupal in China.

I'll end my two week trip in Tokyo, Japan. My time will be split between meeting the local Drupal community - https://groups.drupal.org/node/440198, understanding the adoption rate of Drupal in the Japanese market, and attending private meetings with digital agencies, Acquia partners and others to learn about the state of the web and digital in Japan.

Xièxiè and dōmo arigatō to those that have helped plan these events and gather the Drupal community for some fun evenings!

If you aren't able to make either Drupal meetup, feel free to leave your thoughts in the comments.

A better runtime for component-based web applications

I have an idea but currently don't have the time or resources to work on it. So I'm sharing the idea here, hoping we can at least discuss it, and maybe someone will even feel inspired to take it on.

The idea is based on two predictions. First, I'm convinced that the future of web sites or web applications is component-based platforms (e.g. Drupal modules, WordPress plugins, etc). Second, I believe that the best way to deploy and use web sites or web applications is through a SaaS hosting environment (e.g. WordPress.com, DrupalGardens, SalesForce's Force.com platform, DemandWare's SaaS platform, etc). Specifically, I believe that in the big picture on-premise software is a "transitional state". It may take another 15 years, but on-premise software will become the exception rather than the standard. Combined, these two predictions present a future where we have component-based platforms running in SaaS environments.

To get the idea, imagine a WordPress.com, SquareSpace, Wix or DrupalGardens where you can install every module/plugin available, including your own custom modules/plugins, instead of being limited to those modules/plugins manually approved by their vendors. This is a big deal because one of the biggest challenges with running web sites or web applications is that almost every user wants to extend or customize the application beyond what is provided out of the box.

Web applications have to be (1) manageable, (2) extensible, (3) customizable and (4) robust. The problem is that we don't have a programming language or an execution runtime that is able to meet all four of these requirements in the context of building and running dynamic component-based applications.

Neither PHP, JavaScript, Ruby, Go or Java allow us to build truly robust applications as the runtimes don't provide proper resource isolation. Often all the components (i.e. Drupal modules, WordPress plugins) run in the same memory space. In the Java world you have Enterprise Java Beans or OSGi which add some level of isolation and management, but it still doesn't provide full component-level isolation or component-level fault containment. As a result, it is required that one component pretty much trusts the other components installed on the system. This means that usually one malfunctioning component can corrupt the other component's data or functional logic, or that one component can harm the performance of the entire platform. In other words, you have to review, certify and test components before installing them on your platform. As a result, most SaaS vendors won't let you install untrusted or custom components.

What we really need here is an execution runtime that allows you to install untrusted components and guarantee application robustness at the same time. Such technology would be a total game-changer as we could build unlimited customizable SaaS platforms that leverage the power of community innovation. You'd be able to install any Drupal module on DrupalGardens, any plugin on WordPress.com or custom code on Squarespace or Wix. It would fundamentally disrupt the entire industry and would help us achieve the assembled web dream.

I've been giving this some thought, and what I think we need is the ability to handle each HTTP request in a micro-kernel-like environment where each software component (i.e. Drupal module, WordPress plugin) runs in its own isolated process or environment and communicates with the other components through a form of inter-process communication (i.e. think remote procedure calls or web service calls). It is a lot harder to implement than it sounds as the inter-process communication could add huge overhead (e.g. we might need fast or clever ways to safely share data between isolated components without having to copy or transfer a lot of data around). Alternatively, virtualization technology like Docker might help us move in this direction as well. Their goal of a lightweight container is a step towards micro-services but it is likely to have more communication overhead. In both scenarios, Drupal would look a lot like a collection of micro web services (Drupal 10 anyone?).

Once we have such a runtime, we can implement and enforce governance and security policies for each component (e.g. limit its memory usage, limit its I/O, security permission, but also control access to the underlying platform like the database). We'd have real component-based isolation along with platform-level governance: (1) manageable, (2) extensible, (3) customizable and (4) robust.

Food for thought and discussion?

Open Source and social capital

The notion that people contributing to Open Source don't get paid is false. Contributors to Open Source are compensated for their labor; not always with financial capital (i.e. a paycheck) but certainly with social capital. Social capital is a rather vague and intangible concept so let me give some examples. If you know someone at a company where you are applying for a job and this connection helps you get that job, you have used social capital. Or if you got a lead or a business opportunity through your network, you have used social capital. Or when you fall on hard times and you rely on friends for emotional support, you're also using social capital.

The term "social" refers to the fact that the value is in the network of relationships; they can't be owned like personal assets. Too many people believe that success in life is based on the individual, and that if you do not have success in life, there is no one to blame but yourself. The truth is that individuals who build and use social capital get better jobs, better pay, faster promotions and are more effective compared to peers who are not tapping the power of social capital. As shown in the examples, social capital also translates into happiness and well-being.

Most Open Source contributors benefit from social capital but may not have stopped to think about it, or may not value it appropriately. Most of us in the Open Source world have made friendships for life, have landed jobs because of our contributions, others have started businesses together, and for others it has provided an important sense of purpose. Once you become attuned to spotting social capital being leveraged, you see it everywhere, every day. I could literally write a book filled with hundreds of stories about how contributing to Open Source changed people's lives -- I love hearing these stories.

Social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.

To bean or not to bean?

Last weekend our Nespresso machine died in front of my eyes. Water started leaking from its base during use and it shorted the electricity. It was a painful death. I'm tempted to take it apart and try to repair it but it also brings up the question; what to buy next?

Part of me enjoys the convenience of the Nespresso machine, the other part of me is eager to buy my first "serious" espresso machine.

See, I'm a coffee lover. That is to say, like most of the people living in the US I have a coffee addiction, and have been brainwashed into spending more and more on my daily coffee intake. To make matters worse, we live in a society where we call the people who make great coffee "artists". I'd love to practice some coffee artistry myself and make that perfect barista-grade cup of coffee.

I did a little bit of research and picking an espresso machine is not easy. It turns out this is a complex space. The choices range from super-automatic machines (e.g. they do everything from grinding, dosing, tamping to brewing) to semi-automatic machines (e.g. you manually grind your own beans and tamp them) to manual machines (e.g. you control how long the brewing water sits over the bed of coffee, resting as it were at neutral or boiler pressure). There are even "coffee schools" that offer classes and certifications to become a professional barista.

While I love the smell of fresh ground coffee and an above perfection espresso, I also don't want to take 15 minutes to make a cup of coffee. I usually need my first cup of coffee to help me wake up and I'm often crunched for time, so I don't want it to be super complicated.

Espresso or Nespresso? To bean or not to bean? Help!

Drupal.com refresh launched

Back in the early days of Drupal, Drupal.com looked like this:

Drupal.com in 2005

Drupal.com as launched in 2005.

On August 14 2009, I relaunched Drupal.com to replace the oh-so-embarrassing placeholder page. The 2009 re-launch turned Drupal.com into a better spotlight for Drupal. It wasn't hard to beat the white page with a Druplicon logo.

Drupal.com in 2009

Drupal.com as launched in 2009.

What was a good spotlight five years ago though is no longer a good spotlight today. Five years later, Drupal.com didn't do Drupal justice. It didn't really explain what Drupal is, what you can use Drupal for, and more. Along with sub-optimal content, the site wasn't optimized for mobile use either.

Today, exactly five years later to the day, I'm excited to announce that I relaunched Drupal.com again:

Drupal com devices

Redesigning Drupal.com to make it more useful and current has been one of my New Year's resolutions for a number of years now. And as of today, I can finally strike that off my list.

The new Drupal.com has become richer in its content; you'll find a bit more information about Drupal to help people understand what Drupal is all about and how to get started with Drupal. On a desktop, on a tablet, on a phone, the site has become much easier to navigate and read.

I believe the new Drupal.com is a much better, more relevant showcase for Drupal. The goal is to update the site more regularly and to keep adding to it. My next step is to add more use cases and to include short demo videos of both the Drupal backend as well as the showcases. Drupal.com will become an increasingly helpful resource and starting point for people who are evaluating Drupal.

Drupal com mobile

The changes are not limited to content and look; Drupal.com also has a new engine as the site was upgraded from Drupal 6 to Drupal 8 alpha (don't try this at home). We're using Drupal 8 to push the boundaries of site building and responsive design and to uncover bugs and usability issues with Drupal 8. Because we're using an alpha version of Drupal 8, things might not function perfectly yet. We’d still love to hear feedback from designers and front end developers on how it’s working.

Pages

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.