Robert Douglass initially crated a lot of buzz about this topic via his now famous Tweet several weeks ago. The purpose of the tweet was to croudsource a community response to a concept and to build tension for his upcoming presentation in Brussels about the topic. Since, there have been numerous articles and discussions about the topic - mainly those by famous Drupal folks here, here, and here.
Essentially, the notion of the appstore is to create a marketplace for the sale of Drupal applications as products. This is an inherently confusing topic that is difficult to even conceptualize. What does it mean for developers? What about the GPL? What is really being sold?
There is a lot of yelling and noise about all of this, and I think a significant amount of mis-interpretation about what an app store is, and what it would really mean to the community. Simply put:
A Drupal appstore would represent a marketplace independent of Drupal.org that would allow developers to sell their Drupal applications.
First, and foremost - this is not a license to violate the GPL. Nobody is talking about doing something akin to the recent Wordpress fiasco. We are talking about charging for code, but not taking code that was open and making it private or illegal to use unless you've paid for it.
The problem of products
Presumably, any app store that would sell products would exist independently from drupal.org, and would represent a different set of code for modules, themes, and distributions. This would generate a passive revenue stream for developers / firms that wanted to list their wares on the appstore.
Nearly every Drupal shop I've spoken to since becoming involved in the marketplace has wanted to develop a true product offering around Drupal. This has three really difficult challenges that I don't think anyone has fully surmounted:
- It's really really expensive. Building a product costs a tremendous amount of money, and if you happen to have the money you still need to have the time to build a product outside of everyone trying to build and implement other sites. The nature of the business is to cannibalize product development in favor of services revenue with customers that are paying you now.
- Where do you sell your product once you've built it? You or your company has just built a Drupal system that literally revolutionizes the web with its innovative ideas, but how do you tell people about it? How do you prove it's usefulness? Can you bear the time and cost associating with building a sense of value around your new product?
- Fundamentally, this is still open source. No matter what you do your code can be copied and your service offering can be mirrored by others who may have implicit marketplace advantages (more established, better services team, more clients to market your product to).
Say you take the tremendous time and energy required to build a product, and you actually manage to sell it to a customer. What value did they receive? If it's not illegal to use, resell, or redistribute code from this appstore-to-be… what are you really selling?
The problem of services
Most Drupal shops exist as service businesses. They sell the time it takes their developers to build sites marked up to cover the overhead it takes to sell those sites, pay their people, and maintain an office (and hopefully make some profit).
This is an inherently challenging business because your organization can only grow as fast as the sites you sell (which typically have a lengthy sales cycle), and you can only realize the revenue from those sales by billing time against those projects. Once you've delivered a site to a client, the majority of the value your organization provided that client has already been realized, and you're left needing to make another sale to continue to keep your staff busy billing more time. It's inherently both risky and challenging to manage the constant struggle of services sold versus services billed.
That's not to say it's impossible to responsibly manage and maintain profitability within a services business, but it's certainly more difficult to value, grow rapidly, and show long-term sustainability.
There is also a problem of just simply selling packaged development time along with a brand of a product. These are pseudo-products that take the form as fixed services offering and a fixed price for a particular set of services (e.g. setup and installation or support). Sure, it's great to market your Drupal application and say "For $X I'll set up my application for you, maintain it, and support it." However, this inherently little better than just listing your application on drupal.org (and strongly attaching your name to it) as you're still at least mostly limited by the number of hours you or your company can bill against a client. Sure, you can sell maintenance contracts to clients, but they come with the implication that you'll be spending time either actively supporting that client or actively improving your product via a new version. Ultimately, your still bound by the time you an bill, and clients are quick to recognize the value of the support or maintenance that they're paying.
What's been tried?
Often you hear about organizations trying to create products out of open source projects, and also create marketplaces around those open source projects. Joomla modules, Wordpress themes and plug-ins, and many Drupal themes are sold in marketplaces. There is also a lot of stark debate around these markets and the affect they have on developers and communities.
Taking these open source applications and creating products and marketplaces is highly similar to how we go about paying for players in sports within the United States.
Here, you cannot be a paid collegiate athlete and play for a college or university within the NCAA (of which nearly all are a part). It's often cited that this ensures that players play "for the love of the game", or that inherently wealthy schools do not have a significant advantage over less fortunate ones. Whereas professional sports players do get paid, and they have collective bargaining rights that work with leagues to determine appropriate athlete compensation.
Building an appstore, in the sense that Robert and others are talking about, is their version of trying to allow for developers to "go pro".
Much like collegiate athletes, Drupal developers or companies have limited collective bargaining capabilities and no ability to really get paid for their work on contributed code (except in certain cases for hours they're billing as a paid contribution). A marketplace would allow for developers or companies to be paid beyond that initial contribution by others that use their code.
This brings up a rash of issues like "Will developers in Drupal still work on projects where they're not being paid?" and "Won't we lose some of our community culture because suddenly Drupal will be more about money than 'for the love of Drupal'?" These are serious issues, but more serious is this:
Regardless of any argument I've ever heard, professional athletes are paid in rough proportion to the revenue they help to generate by their efforts. This is kept roughly in-check by collective bargaining. Collegiate players are not paid any income regardless of their contribution to revenue for the school. In the pros, the money goes to the people that work to earn it, in college, it keeps the wealth at the level of the institution, coaches, and the athletic association.
There is a direct corollary to the distribution of wealth in the Drupal community. Players are developers. Institutions are our prospects and clients (which is arguably a good thing both in college and in Drupal). Coaches are Drupal firms which can and do profit greatly from exceptional Drupal talent. The Athletic Association is other Drupal firms and any 3rd party products that profit by being integrated with Drupal solutions.
So, should more money go into the hands of the shops building these solutions through their hard work, or should it be kept away from them because of the concerns we have over how it will affect us?
Creating a Marketplace… and Curating it
A Drupal developer or Drupal shop's version of collective bargaining is creating a for-pay marketplace. It's inevitable that within an open source project of the size and scale of Drupal there are those that are going to feel like they're not being adequately compensated for their contributions to the community and alternative marketplaces will spring up.
Despite the issues listed above about having open source products or packaged services, management and curation of that marketplace becomes a significant issue. How to you ensure that a marketplace like this is successful? If it's supported by just one company then it offers obvious advantages that quell adoption by others. If it's curated by an independent or collective association how is revenue divided and shared? Who maintains it? Who manages the revenue generated and manages where that money is supposed to flow? How to you resolve the inevitable marketplace disputes that will arise over quality, security, and the propriety of certain applications?
Is services the solution?
Nearly all Drupal shops, and a signifiant amount of developers, want to explore new opportunities and ways of generating more revenue. Most also support the goal of capturing more of the web market with Drupal. in the process we want to create new products and new marketplaces for those products. Because of significant challenges associated with doing this, it's going to be a struggle to be successful, and it will likely take several iterations to better understand the potential for success of these ideas and to gage the potential impact on the community. However, I consider this a natural part of a mature software industry, and we will almost certainly see all of this come to pass. Regardless of your personal convictions, there is a growing movement of those that want to "go pro" in Drupal, and nothing is there to stop them from trying.
One interesting idea that does mitigate a lot of the problems around products, services, and marketplaces described is offering Drupal functionality as a service. Providing software-as-a-services (SaaS) models within open source has been proven effective in several different circumstances. In fact, some are arguing that open source and SaaS are becoming highly intertwined. SaaS offerings have the advantage of being able to scale without the involvement of additional staff. The convenience value and scalability of SaaS solutions provides a value to clients that they're willing to pay for. Also, curation of a marketplace doesn't really become an issue because every individual firm is able to create their own offering, or host complimentary offerings on the other's behalf (which is typically a much simpler business contract than a contract to enter a marketplace arrangement). SaaS still has some disadvantages of having a cost associated with building a system, being somewhat limited in its offering, and requiring the ability to build a large customer base. However, I believe that a business model for this exists within the Drupal model, and it may be the most successful way we can "go pro".