You are here
Over the past twelve months, I’ve become a bit of an obsessive follower of Bitcoin. It started after I read Satoshi Nakamoto’s original Bitcoin paper. It was a fascinating read and my first introduction to crypto-currencies. I even had a couple of lunches in Boston with Gavin Andresen, Bitcoin’s current project lead.
I was close to buying some Bitcoin when I first got interested, but backed off. It was too bad because Bitcoin's value increased from $13 a year ago to around $1,000 at the time wrote this: a 4,000% increase in 12 months. I didn't buy my first Bitcoins until a month ago. I bought them with some reluctance but I figured that people felt a certain reluctance when paper money first came along. But I bought them because to me it seemed like Bitcoin could work and also because I wanted to have a better understanding of what it was all about.
Bitcoin is a purely digital currency. There are no records of Satoshi's identity so no one knows who invented it, no one controls it and it is not backed by gold. It is something akin to a digital version of gold. It's fascinating. At the core of the Bitcoin system is a global, public log, called the "blockchain", that records all transactions between Bitcoin clients. A user can send Bitcoins to another user by forming a transaction and committing it to the blockchain. The blockchain is maintained not by a central body, like a central bank, but by a distributed network of computers, called "miners". Everyone can be a miner, and the miners collectively record and verify all transactions.
Compared to traditional banks, the advantages of Bitcoin are significant. Bitcoin payments can be made at any day of the week, any time of day to anywhere in the world. The fees and delays involved are small compared to those imposed by banks; pennies compared to dollars and minutes compared to days. And unlike paper money, it is unforgeable. Unlike gold, its supply is perfectly verifiable. It is also immune to inflation: governments can't print more Bitcoins to pay off their debts.
The design and architecture of Bitcoin is both a curse and a blessing. The lack of central authority governing Bitcoin raises questions. Governments tend to enjoy power of observation; it makes it easier to fight money laundering, tax evasion and other crimes. As Bitcoin continues to gain popularity, governments may grow increasingly resistant and attempt to shut down Bitcoin. And banks don't like Bitcoin either. Money transfer is an important part of their business; it has almost zero risk, almost zero cost, yet provides them billions of dollars in revenue. In a world where Bitcoin is universally accepted, banks may have a diminished role.
The jury is out on whether Bitcoin is a fantasy destined for failure, or whether Bitcoin will underpin the future of finance. Some predict the value of one Bitcoin could climb to hundreds of thousands of dollars if it becomes universally accepted. While I risk losing some money, it could also turn out to be a massive investment home-run. I felt that the risk/reward decision made it a bet worth taking.
I certainly don't advise you to buy Bitcoin as I'm skeptical that Bitcoin will succeed. I predict Bitcoin to have an extremely bumpy ride, and at best, to follow Gartner's hype cycle. If Bitcoin ends up collapsing, I will be disappointed but I won't feel stupid. I already sold some Bitcoin and recouped my original investment; I'm long with my remaining Bitcoin.
So is Bitcoin a case of speculative greed, or a utopian cyber-libertarian ideology? In a world where everything is going digital, why not currencies? Bitcoin makes it faster, cheaper and easier to store and transport value. It was designed to overcome problems faced with traditional currencies and banks. At a minimum, Bitcoin has created a lot of debate throughout the world, and has shaken a stagnant banking market. Longer term, the concept of a crypto-currency makes a lot of sense to me. It is massively beneficial for the world that we can transfer money easier, faster and cheaper. I find it hard to believe that a hundred years from now, we'd still be digging up gold, and that we wouldn't have a global, digital currency to replace it.
If you believe a digital currency is the future of money, I'll leave you with one question: how would one launch a world-wide crypto-currency like Bitcoin? It can't be owned by a commercial organization, and I simply can't imagine all the world's governments work together to build and launch something like this. Creative disruption often comes from the outside, and not from the inside. It pretty much has to happen in a grassroots way, not unlike the way the Internet was created. Even today after 30 years, the Internet operates without a central governing body and is comprised of independent, voluntarily networks. It works well and changed the world.
There has been a lot of chatter about Drupal 8. Will Drupal 8 be performant? Will Drupal 8 be easy to develop modules for? Will I have to learn Symfony? I want to address these concerns and explain why Drupal 8 introduces such big changes.
Lessons from the past: the pain before the gain
The reason Drupal has been successful is because we always made big, forward-looking changes. It’s a cliché, but change has always been the only constant in Drupal. The result is that Drupal has stayed relevant, unlike nearly every other Open Source CMS over the years. The biggest risk for our project is that we don't embrace change.
The downside is that with every major release of Drupal, we've gone through a lot of pain adjusting to this change. I first wrote about it in 2006 when trying to get Drupal 4.7 released:
"So let's capture that thought for future reference. Sweeping changes are required to make major advances in technology, and often times there is a lot of pain before the pay-off."
We decided that big changes were required
Drupal 7 is a fantastic CMS, but at the same time there are some fairly big limitations, including an incomplete Entity API, a lack of separation between content and configuration, leading to deployment challenges, a lack of separation between logic and presentation in the theme layer, and more. We created solutions for those challenges using contributed modules, but those solutions were in many cases incomplete. In Drupal 8, we decided to tackle a lot of these problems head-on, through the Configuration Management Initiative, the Twig templating layer, and a complete Entity API.
The web landscape has also dramatically changed around Drupal since January 2011, when Drupal 7 was released. Mobile browsing is ubiquitous, and so are third-party services that people may want to integrate their Drupal sites with. Web site users expect a much higher bar when it comes to ease of use. We anticipated these trends and as a result, we spent the past 2.5 years working on Drupal 8's mobile features and user experience improvements.
But are all these great improvements enough?
We need to modernize Drupal 8
One of our biggest challenges with Drupal, is that it is hard for organizations of all sizes to find Drupal talent (developers, themers, site builders, etc). Drupal 7 didn't address this problem (e.g. we held on to procedural programming instead of object-oriented programming), and in fact made it a bit worse with the introduction of even more "Drupalisms" (e.g. excessive use of structured arrays). For most people new to Drupal, Drupal 7 is really complex.
The most effective way to address the Drupal talent issue, as well as the complexity issue, is to bring Drupal in line with modern frameworks and platforms, so there is less Drupal-specific knowledge to learn in order to become proficient. We decided to adopt modern PHP concepts and standards, object-oriented programming, and the Symfony framework. While a lot of the Drupal concepts (Fields, Views, Entities, Nodes) continue to exist in Drupal 8, they are now implemented using object-oriented programming design patterns.
The advantages and disadvantages of object-oriented programming are well-understood. The disadvantages are size, verbosity, the amount of work it takes to write (including the design planning that goes into it) and slower performance. For people new to object-oriented programming there may be a steep learning curve; some of the key programming techniques, such as inheritance and polymorphism, can be challenging initially. The advantages are encapsulation (both to hide implementation details and to avoid tampering with internal values), faster development thanks to re-use, extensibility, and better maintainability. Compared to procedural programs, object-oriented programs are easier to maintain, extend and refactor. So although a lot of work is spent to write the program, less work is needed to maintain it over time.
For Drupal 8 this means that the code will be more abstract, more verbose, and slower, yet also be more maintainable, more modular, and more accessible to non-Drupal developers. The end result is that Drupal 8 should help us attract new people to Drupal in a way Drupal 7 didn't.
This is exactly what happened with other projects like Symfony; Symfony 2 was a complete rearchitecture of Symfony 1. A lot of people were alienated by that, yet at the same time Symfony 2 took off like a rocketship. The same thing has happened with the major releases of Drupal as well, despite how much change each one brings.
Change is scary for the existing Drupal developers
However, as we get closer to the release of Drupal 8, existing Drupal developers have become increasingly aware of the massive changes that Drupal 8 will bring. This has resulted in some fear; some people feel like they have to re-learn everything they know, and that developing for Drupal 8 has changed to the point where it's no longer fun. This fear is completely understandable. Change is hard, it can be scary, and often takes a long time to be absorbed.
But even if we completely streamlined the Drupal 8 developer experience, Drupal 8 will still look and work radically different under the hood. As mentioned, there are advantages and disadvantages to object-oriented programming and modern design patterns. But if we care about the long-term success of Drupal, we can't preserve the past. The risk of sticking with the old Drupal 7 architecture is that we won't be able to attract many more Drupal developers, and that over time, Drupal will become the odd one out.
There is a lot of work left to be done
Part of the fear out there is well-founded because in the current state of development, Drupal 8 isn't good enough. While there are many things to like about Drupal 8, I'm also the first to admit that we have work to do on the Drupal 8 developer experience (as well as performance) before Drupal 8 can ship. Creating a well-designed object-oriented application takes more time and design work than creating a procedural one. Some major improvements have already landed, but we're still working hard on improving the developer experience. We need more help, especially from Drupal 7 developers, on how we can make Drupal 8 more approachable for them. I'm not afraid to make major API changes if the developer experience improvement is suitably large. So if you have concerns about Drupal 8, now is the time to step up and help. In return, I promise we'll work on Drupal 8 until it is ready. Thank you!
Every week, I get asked the "Silicon Valley question". This week alone, it came up at least three times. I had a phone call with a Belgian start-up asking me for my thoughts on whether to start their company in Belgium or in Silicon Valley. This afternoon, iMinds, a Belgian research institute that promotes entrepreneurship, visited me at Acquia to talk about similar topics.
There are advantages and disadvantages to being in Silicon Valley, and we could argue them to death. Not every great technology company is based in Silicon Valley, and there are many successful entrepreneurs who aren't in the valley. However, I bet you that deep inside every one of those entrepreneurs wonders whether it wouldn't be better to be in Silicon Valley. More often than not, it actually would be better.
This morning I got a message from Bart Becks, a well-known Belgian entrepreneur and angel investor. He asked for my thoughts on an article he is writing about whether Europe could replicate the Silicon Valley phenomenon. To me, this is the more interesting "Silicon Valley" question.
Europe has no choice but to reinvent itself to become more like Silicon Valley. Entrepreneurs, not the government, will actually change the world. While the government's role is to foster entrepreneurship, clearly the government on its own isn't capable of changing Europe fast enough.
Silicon Valley is a state of mind. To recreate Silicon Valley in Europe, Europe has to adopt Silicon Valley's culture first. That culture has developed around the desire to continuously reinvent everything, including oneself. That is what keeps Silicon Valley relevant, and what Europe needs to emulate most. Once Europe has established a Silicon Valley-like culture, it can slowly mix in the other ingredients that make Silicon Valley successful: money, smart venture capitalists, better engineering talent, better creative talent, and more. But let's start with the culture.
There are other aspects of the Silicon Valley culture that all of Europe should adopt. The Silicon Valley culture encourages people from all over the world with different cultural backgrounds and diverse skills to physically come together, inspire each other, and try to accomplish something unique and game-changing.
I also believe that Europe should adopt part of the American Dream: the egalitarian belief that everyone is able to succeed through hard work, and that it is acceptable and encouraged to better oneself economically through hard work. It doesn't mean Europe needs to give up its strong communal beliefs and its desire to look out for the greater good. I hope the European financial crisis represent a watershed moment that causes Europe to rethink some of its current models.
America's social history wasn't necessarily pretty, but it has created a culture where multiculturalism, ethnic diversity and thoughtful capitalism are part of the national character. I'm worried it may take Europe a couple generations to truly embrace such a culture. Until that happens, we'll see some regional and national successes, but not the European-wide "Silicon Valley" culture that Europe needs to successfully reinvent itself.
For Acquia, 2012 was a great year. In many ways, it's been our best year.
Last year, we saw more evidence of Drupal continuing to become a growing part of the mainstream. While this trend has been apparent for some time, in 2012 we were being adopted at a faster rate by more and more enterprise businesses and government agencies. Acquia, in many ways, has risen on the tide of this acceptance. Maybe we helped build this momentum. And along the way, as we've grown, we have worked to keep the philosophy of open source as the guiding philosophy of Acquia.
The Open Source Way
The concept of being guided by the philosophy of open source, which I call the Open Source Way, is reflected in Acquia's approach to our products and services. For example, we believe it is important to provide the capability to easily transfer data from one platform or solution to another, and not be shackled to proprietary vendors' platforms. The solutions we offer, whether PaaS or SaaS, allow innovation and agility by following the open source way, eliminating lock-in. We've coined the terms OpenSaaS and OpenPaas to refer to this.
This approach has resonated with enterprise business. This is reflected in our growth metrics for 2012. Our growth was reflected in our sales bookings, which grew at a record rate. We finished the year with 15 consecutive quarters of revenue growth, surpassing even our own aggressive goals.
Acquia grew by more than 160 employees last year, and now totals about 280 staff. In addition to Acquia's base in Burlington (Boston, MA), we have 28 employees in the UK office, 14 in our new Portland office, and 82 working remotely. Success poses many challenges. Hiring so many people is difficult. On one recent Monday, we have about 20 new staff undergoing orientation in our Burlington office. We've met the challenge of hiring, though, and we've assembled a staff of talented, passionate people. They are the reason for Acquia's success.
Our core strength is our ability to accomplish the aggressive goals we set for ourselves. This ability is the result of both the collaboration and the passion the Acquia staff brings to everything we do. Acquia's culture, in which collaboration and passion are key, also reflect the Open Source Way. We bring this passion and collaboration to our customers as well, and we work hard to ensure every customer's success. In 2012, the number of customers renewing with us was up, returning that commitment and loyalty.
Landmarks and trends
As we moved through 2012, we saw the growing acceptance of cloud computing. No longer was it "should we be on the cloud", but businesses asked "how best to move to the cloud". More often, the open, elastic cloud computing offered by Acquia was the answer. Platform as a Service (PaaS) and Software as a Service (SaaS) both continue to gain further acceptance and grow, again providing that ability to react to business needs rapidly, putting a larger portion of resources into building exactly what is needed when it is needed, rather than investing in expensive infrastructure and maintenance. The success of our cloud products means that Acquia will continue to invest and expand in this area in 2013, especially as we saw the trend last year that having many microsites, often one for each product or service, is quickly becoming the rule rather than the exception.
Other landmarks in 2012 were the growing number of health/pharma businesses moving to Drupal and the cloud, joining financial services companies and government agencies also making the move. Until recently, these industries were wary of open source and cloud-based services, fearing that these solutions weren't secure or reliable enough. The reality that the cloud can also be fault-tolerant and highly available, and that security and government compliance requirements can be met with confidence, opened up the cloud to more and more enterprise businesses in 2012. Their move to the cloud in 2012 reinforced the fact that freedom of innovation and agility of open solutions are driving factors for large-scale business as well as smaller organizations.
As the public moves rapidly to mobile platforms of all kinds, including smart phones and tablets, the need to provide a great user experience on these platforms is becoming increasingly important. UX also became important in 2012 as marketing rather than IT became the driving force behind more and more websites. Acquia responded with the creation of our Spark team, which took shape as a five-person team made up of some of the world's best Drupal experts.
Also in 2012, Acquia acquired Mollom, a company I created to address the challenge of managing social spam on websites. With the tremendous growth of user-generated content as part of the social media explosion, unwanted content has become a more important issue to take on. As a SaaS tool, Mollom fits in with Acquia's existing services.
In 2012, Acquia continued to invest in the worldwide Drupal community in a number of important ways. First, we sponsored over 82 Drupal events around the world in 2012. These events brought new people into Drupal and helped existing Drupal users learn new techniques. We employ more than 110 Drupal specialists, most of whom are significant contributors to the larger community. We've sent our Drupalists to more than 30 of these events (as well as hosted sprints ourselves at Acquia) to collaborate with others in the community on important problems for Drupal.
We also grew Acquia's Office of the Chief Technical Officer, or OCTO, in 2012. OCTO includes a dedicated team who work on Drupal full-time, on projects that include:
- Drupal core architecture issues.
- Authoring experience improvements via Spark.
- Spearheading process changes that help the community work better together.
- Forming the Large Scale Drupal program, which helps pool resources of numerous enterprises to provide solutions the benefit the entire community.
This year, like 2012, will be a key year for Acquia as we continue to develop products and services built on the open source philosophy.
Life-cyle management applications will be an increasing focus for Acquia in 2013. These applications will help craft great digital experiences by providing the tools to monitor and optimize digital content.
Of course, we'll continue to nurture and expand our vision of OpenSaaS and OpenPaaS. We'll continue to make the move to PaaS even easier, providing solutions that offer all of the functionality needed, but in a simplified package. We'll accomplish this by combining PaaS, Drupal services and Application Performance Management to produce comprehensive solutions that continue to make Acquia a no brainer when it comes to choosing a PaaS provider. PaaS platforms that embrace an open ecosystem provide faster business value, as many of our customers have discovered. We are working with our growing number of partners to help them build customer solutions on our open cloud platform.
As we start down the road of 2013, we enter the year just having raised $30 million in Series E financing, the single largest financing we have done to date. As we have grown and matured during 2012, these funds will assure sustained growth and success in 2013. No matter how rapidly we grow, or how large the Drupal community becomes, Acquia will put its open source philosophy at the core of all the work it does. In the end, the people of Acquia and the Drupal community, following this philosophy, are building the future of the digital experience. The Open Source way.
As mentioned last month, on July 16 - 17, 2012, several community leaders in the Drupal project sat down with several community leaders from other open source projects and tried to hash out a governance structure to support the Drupal community's continued growth. "Governance" in this case, encompassing all the things we do to organize ourselves, make plans and decisions together, get things done, and resolve conflicts.
Here are the proposals we came up with, and we are actively seeking community feedback on the ideas within.
What problems are we trying to solve?
We began the sprint by brainstorming a list of problems we're hitting, given the scale of our community. This list included items such as:
- No obvious answer to the question, "Who can make a decision here?" and as a result, important decisions can get stale-mated, or in the worst case leave smouldering craters where a healthy, functioning community used to be.
- Because the Code of Conduct punts on the topic of conflict resolution, a handful of already swamped individuals get tapped on an ad-hoc basis to intervene in conflict situations. This both burns out those individuals, and also leaves the vast majority of the community who don't know who those individuals are with no conflict resolution path apart from "repeat what I already said, but with more volume".
- While our "do-ocracy" model generally works well for our community, it can also lead to situations like "Tyranny of the person with the most time on their hands." We need ways for smart people who can't be on IRC 18 hours a day or read 300+ reply issues to participate and be respected as equals.
Over the course of two days, Drupal community members Dries Buytaert, Angela Byron, Randy Fay, Greg Dunlap, and David Strauss met and discussed a variety of these and other governance topics, and we also received input from Jono Bacon, community manager for the Ubuntu project, Jared Smith, former project lead of the Fedora project, and David Eaves.
Overview of proposed changes
We propose the creation of a number of "working groups" that essentially make more explicit community structures that already exist. Each working group would consist of ~5 people, appointed by Dries, in charge of collaborating with the community in order to establish effective policy. Each working group will have one "lead" member (chair) who communicates major items and works with Dries. Some working groups will have a set duration (e.g. life cycle of a Drupal core release), others may have terms. Dries, as project lead, also reserves the ability to terminate a group at any time if it feels like they are overstepping their scope (charter).
The summary, in essence:
- Establish clearly chartered working groups where currently loosely defined individuals are taking on things that are community-shaping in their scope.
- Empower these working groups to make decisions, so important community governance decisions do not get stalemated. Keep the groups small enough that decision-making can take place efficiently, but large enough that a diversity of opinions are represented.
- Make it more transparent and obvious, to newcomers and community insiders alike, where "the buck stops" with decision-making in our community in various areas, what the structure of the community is, what's expected of them, and who to turn to for help.
The "Drupal" groups encompass areas that touch Drupal core or contrib, or the Drupal community itself. The ultimate "buck stops here" with these groups is with Dries Buytaert, the Drupal project lead.
Inspired by the Fedora Community Working Group, this group would be responsible for maintaining a friendly and welcoming community, and their charter will likely consist of items such as:
- Maintaining and updating community-governing policies like the Drupal Code of Conduct.
- Helping with mentorship and on-boarding of new community members.
- Ensuring existing community members have their needs met.
- Intervening as mediators in cases of conflict resolution (where the conflict cannot be worked out among individuals first) or burnout.
- Issuing sanctions in cases of extreme policy violations.
In other words, this working group tries to make sure the "people" side of our community is functioning well. It doesn't set technical policy or intervene in any code-related matters; this is the role of the Technical Working Group. The ideal make-up of this group would be community-minded people with extreme amounts of patience, empathy, and diplomacy skills.
A corollary to the Community Working Group, this group would set and maintain policies around the technical aspects of our community, including:
- Develop and maintain policies around things such as:
- Establishing best practices and recommendations around bug/issue workflows; for example, strongly encouraging a workflow of idea -> architecture review -> implementation -> code style/clean-up.
- Recommending to the Drupal Association tool changes that will help accelerate contribution.
- Intervening as mediators in cases of technical conflict (where the conflict cannot be worked out among individuals first).
In other words, this working group tries to make sure the "technical" side of our community is working well. "People" problems would be escalated to the Community Working Group. Nevertheless, the ideal make-up of this group would be community-minded people who are also technical, known to be fair, and adverse to making new rules.
A lot of time was devoted at the sprint to discussing Drupal Core, and how to address some of the challenges surrounding its development. For example, there is currently a lot of tapping of internal networks to move things along in core, and those without access to those networks can feel blocked out. It's also very difficult to get an answer as to whether or not something is "core-worthy" until far too late in its development process, making major feature development a risky affair.
The recommendation from the Governance Sprint is something like the following, which would not take effect until the Drupal 9 development cycle.
Drupal Core Initiative Working Group
This group works with Dries Buytaert, the Drupal project lead, in order to tackle strategically vital initiatives within Drupal core. Membership includes the initiative leads. This would entail a bit more formalized structure, including milestones and progress tracking, bi-weekly meetings among the various initiatives, and so on.
This would be essentially formalizing what already exists today with the Drupal 8 initiatives and initiative leads.
At the Governance Sprint, we agreed to continue not to impose any additional governance structure on contrib, by design. This allows contrib to be an incubator not only for technical solutions, but also for governance itself.
The exception would be conflicts between maintainers or maintainers and their users which are not able to be resolved among the individuals. These would then go to either the Community Working Group or Technical Working Group, as appropriate.
Security and documentation teams
We have a few overall "Teams" that touch elements of the product, including the Documentation Team and Security Team (we also discussed the establishment of a Support Team). As part of the new governance model, we recommend creating charters for these teams that make it explicit to others what their roles and responsibilities are, how to join, and what is expected of them. It's likely these charters will be modeled after something like the Documentation Team and Leader Responsibilities page.
"Operations / Administration" groups
These groups act in support of the Drupal project and its community. The ultimate "buck stops here" with these groups is with the Drupal Association board instead of Dries. Many of these have a financial impact on the Drupal Association and greatly affect its ability to get things done in support of its mission.
And what about Drupal.org?
Next to Drupal core, this is probably where we spent the most time discussing. Drupal.org is special, in that it straddles both the community side of things, as well as the operations / support side of things. It functions through a combination of numerous volunteers as well as funding via the Drupal Association for support staff and development on major initiatives.
At the moment, the best place to put Drupal.org seems like it's at a halfway point between the "Drupal" and "Operations" sides of things, and for the charter of this working group to include the necessity to work with the Drupal Association and community members alike. Though eventually, for both legal and simplicity reasons, it would be better for this to be located under the purview of the Drupal Association board.
A few areas there was broad agreement on, however, were the following:
- Split off a separate "Drupal.org content" working group from the "Drupal.org webmasters" working group; different skills/levels of trust are needed for managing the content on Drupal.org versus managing access and performing moderation of abuse.
- Identify a much smaller subset of the Drupal.org webmasters group to form policy for this team. Currently, there are nearly 150 members with "site maintainer" privileges, and they often make and enforce policy on an ad-hoc, individual basis. Community members currently encounter very inconsistent experiences in the queue.
- While the Drupal Association doesn't manage these groups, it's generally expected that the charters of these groups will include directives to collaborate with the DA in their policy-making decisions in order to ensure the financial sustainability of Drupal.org.
We're very interested in community feedback on this direction, either in comments below or privately. We'll provide an update on the progress at DrupalCon Munich.
We encourage everyone to come and get involved in this discussion. As our community grows, it is essential that we come up with a governance structure that matches our core values and allows us our community to be more sustainable for the long haul.
Last weekend, we held a sprint at the Acquia offices for the Web Services and Context Core (WSCCI) Initiative for Drupal 8. This was an important sprint for the future of Drupal. This blog post provides a high-level overview of what was discussed and agreed upon; the different sprint participants will be laying out more technical details in follow-up blog posts.
Overall, a wide range of experience levels, skill sets, and perspectives were brought to the table, with the goal of the sprint being to clearly define the initiative’s scope, get agreement on what we wanted to accomplish and why, and lay out a clear plan for how to accomplish this.
In attendance were:
- Larry "Crell" Garfield, lead architect of the WSCCI initiative
- Daniel "sun" Kudwien, top Drupal core contributor
- Fabien "fabpot" Potencier, lead developer of the Symfony project
- Kris "EclipseGc" Vanderwater and James "neclimdul" Gilliland, who have helped develop and implement the plugin system as part of WSCCI
- Greg "heyrocker" Dunlap, initiative lead of the Configuration Management Initiative for Drupal 8
- Moshe Weitzman, long-time Drupal core contributor
- Angela "webchick" Byron, community cat herder and Drupal 7 core co-maintainer
- Randy "rfay" Fay, Justin "beejeebus" Randall and Alex "effulgentsia" Bronstein, core developers and sane voices of reason with an outside perspective
- Dries Buytaert (me), project lead
The WSCCI initiative, as envisioned by Larry Garfield, was originally set to address Drupal's web services and flexible page layout capabilities. We discovered that both would require significant changes to Drupal core, and it was difficult to build consensus online, so we decided to get together for 3 days and to flesh out what we actually wanted to accomplish, and how.
At the sprint, we first attempted to articulate all of the problems that WSCCI was trying to solve, which included: multiple page layouts, better UI/UX to manage blocks, partial page rendering (ESI, AHAH), contextual blocks, different response types per delivery callback/URL, plugin system / swappable subsystems, lazy loading bootstrap (convert subsystems to PSR-0 classes), infrastructure for building web services, dependency injection, and so on.
We then did a round of voting where we could each choose 3 of those things in order to try to determine which of those were the most important.
Two things became instantly clear during this exercise:
- The items encompassed under WSCCI really spanned at least 3 separate major areas: Web Services, more robust ESI-based layouts (think Panels only more powerful), and cleaning up our underlying toolset to be a more loosely-coupled framework.
- The underlying architecture to support RESTful calls to Drupal that makes all of the other things possible was deemed the most important thing to focus on.
After a good chunk of discussions, all were in agreement to scale back the scope of the initiative to just the "Web Services" piece, and spin off the Layout/blocks/related-UI parts to a separate effort.
Furthermore, some efforts, such as PSR-0 and Unified Plugin system, were only semi-related to the WSCCI initiative in the first place, and just happened to become relevant for it. Work on those efforts will continue as part of the general Framework community efforts.
Fabien was able to offer a tremendous number of insights as to how various Symfony2 components could help provide underlying structure for Drupal core to support Web Services out of the box. Essentially, most of what the WSCCI team had been trying to work toward, in the abstract, was already implemented within Symfony2. While some implementation details were different than what we had in mind, the end result is almost exactly what we have been trying to accomplish. We therefore agreed that the best way forward was to leverage several Symfony2 components within Drupal as a way to speed progress toward that end.
Some of the concrete benefits that would come out of these changes are
- An underlying framework that is a first-class REST citizen. That means developing web services becomes easier and more efficient, because the plumbing is already in place. An HTML page is a particular case of a REST service.
- Because the core system will be fully REST-ified, we'll be able to improve existing APIs and expose Drupal content in a natively RESTful way. For example, our current AJAX system doesn't comply with REST standards, but with these changes, can be cleaned up to do so.
- That in turn makes Drupal-to-Drupal communication, content staging, content sharing, and a host of other related tasks easier.
- The use of widely used libraries and techniques makes Drupal more approachable to new developers.
Why does this matter?
As it has evolved into an increasingly powerful system, Drupal has gotten increasingly complex and is not as easy to start developing with as it once was. Many developers are nervous about continuing that trend. Managing complexity is a challenge faced by many software projects, and one approach is to use standardized patterns and components.
Due to its long support for PHP 4, as well as some unique needs, Drupal does not take full advantage of standardized patterns and components. The complexity of the custom code that’s used and the non-standard architecture combines to create a barrier to entry for developers new to Drupal (both experienced and novice developers alike).
Meanwhile, the web is constantly changing around us. Web services and mobile are more important than ever, and with that comes the need to have more flexible page and layout capabilities. Now feels like the right time to modernize Drupal’s capabilities to bring it to the forefront of modern PHP systems and web systems in general.
While changing Drupal's core plumbing to address these needs, it's also a good opportunity to do so using more widely understood and modern techniques and libraries. Leveraging the work of a fellow open source community lets us get a jump on these changes to build a more powerful, more flexible, and more easily learnable system in less time than it would take to go it our own.
While these changes may seem large, and some of them are, we believe that they will achieve the right balance between empowering Drupal's design and architecture, and moving toward more modern, standard, well-tested code and techniques to empower a new generation of developers. I hope you are as excited as we are!
Ten years ago, the average organization had one website. Since then, the world has become a more complex place with a diverse set of needs. If you're like most organizations the number of sites you have continues to grow at a rapid clip. You've dipped your toe into the social media waters by setting up one or more blogs, you use microsites for the foundation of your marketing efforts to promote products and events, and community sites to engage with the people who use your products. And of course, you have your corporate website, as well as your intranet and a number of internal collaboration websites for different projects. This is today's reality.
During the past year, I've met with many organizations that have hundreds of sites; some even have thousands of sites. Most of these sites are vastly different in terms of scale, functionality, complexity and longevity. As a result, the level of investment and the time to market requirements are usually very different. Some of the websites are owned by the company's IT department while other websites may be owned by their marketing department.
For most organizations, one tool cannot get the job done, so they keep multiple tools in their toolbox - whether they intend to or not. Unfortunately this is a common scenario in many enterprises. We see many organizations that run on Vignette, but they add WordPress to power their blog, and use SharePoint for their intranet. Managing integration and multiple (proprietary) solutions is not only costly but it acts as a roadblock to innovation and slows time to market when changes are needed.
It can be a complete mess.
CIOs are now waking up; they're realizing that the cost of running twenty different content management systems on twenty different stack configurations is an expensive, unnecessary burden for the organization. They can see that there are cost savings to be made if they standardize. What they want is something more than a content management system: they need a single platform that meets their needs. They need Drupal.
The New York Stock Exchange is launching 30 sites on Drupal. Turner Broadcasting is migrating 80 sites to Drupal. A large consumer pharmaceuticals company might end up with over 3000 Drupal sites. Why? Because Drupal gives their IT team an agile platform to deliver new sites quickly with the breadth of capabilities to meet their needs, but broad enough in scope to serve as a web platform too.
More and more, I see large organizations standardize on Drupal. Drupal's low-cost entry point and open, modular architecture provides the perfect foundation. Drupal is one of the few solutions that can scale from very small to extremely large, and has the depth and breadth of functionality to support thousands of different use cases. Drupal sites can span a wide range of functionality; from blogs, to marketing microsites, social business community sites, corporate intranets, e-commerce sites and more. There are incredible success stories for each of these use cases already. Plus, we've now reached a point where many open source content management systems outperform proprietary solutions on technical superiority and pace of innovation. Drupal is in a very unique position.
This is an immensely powerful trend. If we navigate this well, Drupal could become truly ubiquitous and go from powering 1% of the web, to quickly powering 5% of the web and even further. It requires us to keep making Drupal a better platform, to crack the code on how to make Drupal distributions truly compete with commercial point solutions, and to build out an even larger commercial ecosystem and community. Needless to say, I'm super excited about Drupal's future and the opportunity ahead of us.