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?
Misconceptions
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".
Comments
This is well thought out on
This is well thought out on various levels. I'm thinking that Acquia and Dries will figure into the "official" marketplace because they have more flexibility over the licenses for the code that is out there, especially since D8 is up on the drawing board, so that has to be taken into momentary consideration, for the viability of alternative marketplaces to live in the ecosystem. The attractive part about using marketplaces is in the ability to pool resources, among other benefits, similar in some ways to buying a franchise, but a nascent company may not realize that they're limiting the ability to control their fate, but perhaps it's like having a fear of flying, even though you're more likely to get in a car accident if you only look at the numbers, vs looking at the legacy impact of business choices big corporations have made, like MS still supporting IE6, or drupal's lack of themes. A marketplace seems to trade a better process for profitability in exchange for having a flexible business model, hence the M&A strategies of big corporations.
Thinking about this a little
Thinking about this a little more, the BSD license has some successes, but a GPL or dual license product base seems more questionable, because of the possibility of having to give up source code as outlined for 3rd parties. It took much time and efforts for OSX and RHEL to be where they are now. My assumption is that in general open source makes the product market pie smaller, while the service market pie can go either way. Non-perishable goods are a more durable store of value compared to bits or a variety of consumables, which translate into wealth on average.
The dual-license track seems the most likely avenue to steer both sides of the development groups, community and commercial, but then again, companies/orgs with open source products can be bought out, presenting some challenges to adoption by the marketplace. SQlite3 is the only exception that I know of, since it's in the public domain, but it doesn't bring any obvious business benefits to the table.
Aside from licenses, which factors affect adoption rates the most? What if Amazon or some deep pockets got in the business? Is the market big enough to justify the investment? How could non-profits react? Hard to say for now.
Dries has a lot to say about this
http://buytaert.net/open-source-in-the-enterprise-and-in-the-cloud
Adoption within enterprise is not really a bad thing - much like Drupal being noticed by large systems integrators (e.g. IBM, CapGemini). Driving an enterprise ecosystem is generally a good thing. However, these new markets are difficult for the current Drupal players to get into. Honestly, it's even difficult for Acquia (though we're having pretty good success). Involving our partners in this ecosystem is one of the big goals of Acquia. We want to push Drupal into enterprise, and we're trying to have our partners take us there.
However, it's intrinsically difficult to take organizations that don't have enterprise practices, maturity, and philosophy into that space, and not everyone is going to rise to that level. I just hope that some do before the enterprise market it dominated exclusively by large SI's (or companies like Amazon). As we grow, we need the people that make Drupal what it is grow up with it. A lot of people are philosophically opposed to this, and, while I don't think that they'll be crushed under the wheels of progress entirely, I don't see a strong future for them in enterprise Drupal.
Forming marketplaces is a good way for both freelancers and companies in the smaller space to gain notoriety through good work. However, look to have the usual suspects both dominate the marketplace offerings and be the ones that step up and create / curate those markets.