A Drupal app store specification

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
konforti's picture

As part of our strategy, and following Drupalcon London, Linnovate has started investing in an app store, and we are trying to figure out what would be the best format/architecture of a Drupal App Store.
Here are some first thoughts, toward a possible implementation. The goal is to describe a generic app store, that can interconnect with any existing D7 website/distribution.
(excuse the English, grammar etc.)

Any company or individual can set up a Drupal marketplace to offer own or other developer's applications for sale.
A Drupal marketplace involves two components:
A store
- Could be a “Drupal commerce” file store, managing files (apps).

  • A registered user on the store can register a client (Marketplace clients are Drupal websites).
    By doing that, the user is establishing a User - Client - Store relationship which will be the foundation of remote server files transfers.

  • A marketplace store may be set up by a “Marketplace store” distribution.

  • Purchasing an app will be made easy: only one app per order, no cart view.

  • When choosing an app to purchase, the user will be asked to choose a client from her clients list, and approve payment.

  • After purchasing an app it will become available by limitations of: clients(IP Address, domains etc.), ...(more?)

a receipt with a token will be provided. At first, using the store’s address with the receipt code will be used for getting the purchased file from the client site. In later phases the purchased file will be pushed to the selected clients.

  • Each app (product) in the store will have:
    -- A voting option (5 stars)
    -- An option to add a review (comment)
    -- A description
    -- One or more images

  • Any store can have a unique design and branding.

  • Separation of store and storage (a commerce site and appserver site) ???

  • Ability of sharing apps between stores (one storage for few stores) ???
    A client
  • Manages the apps on the website: enable, disable, uninstall. etc.

  • Browsing for new apps will be made by going to the specific store address or by viewing it on the client site in an iframe.

  • A client will manage a stores list from which it is recievng apps

  • A “Marketplace client” is a module installed on the client website.

  • Using the ability of Drupal 7 of remote module installation, the purchased app will be downloaded and installed on the client site, including download and installation of dependencies and other downloadable code mentioned in the app’s manifest.


I-1Marketplace network: the app stores may be, for example, hosted by: Phase2, SubHub, Acquia, Linnovate and hopefuly many other sources.


I-2 Marketplace Client - Store - Storage workflow

AttachmentSize
appstore.png82.4 KB
marketplace transaction.png42.28 KB

Comments

Do you mean "application" as

dgtlmoon's picture

Do you mean "application" as in, applications for windows/android/iphone/iOS or something more sinister like undermining the wider Drupal communities ammoth efforts and good-will to line the pockets of a few private companies?

Nope looks like you really do

dgtlmoon's picture

Nope looks like you really do mean that you want to build something toxic to the Drupal community that serves to line your want-to-be corporate pockets

http://www.linnovate.net/blog/building-drupal-app-store-prolog

So, what you are proposing is something highly toxic to the Drupal community as a whole

  • Any existing project or "application" falls under the GPL licence and may be distributed for a fee but not "sold", you will probably be sued by many organisations that have sponsored countless hours of coding time to contribute back to Drupal and it's projects if you choose to continue the path of distributing code derived from GPL products through a non-public way of accessing those projects or modules

  • This means that you are suggesting that developers switch to coding projects which are entirely closed source by nature, which undermines the whole reason why this community - and thus your venture had the chance to start in the first place.

good luck!

You're entirely wrong.

rupertj's picture

No-one wants to destroy the community. This is clearly in no-one's interests at all. What this initiative is about is providing a really good end-user experience, and cutting down on repetitive work by developers.

The general aim here is that people who've downloaded and installed a Drupal distribution can add to it by going to the app store that that distribution provides (and, hopefully, other sources too), click a few buttons and have the feature they want installed in their site with minimal effort. If people who run an app store want to charge for that app, they can, but they don't have to. And, in my mind, it's entirely reasonable to charge for a finished product. If you're building sites using Drupal for your clients, you're doing this already.

So, is charging for GPL'd software wrong? Go and read this: http://www.gnu.org/philosophy/selling.html . That says unambiguously that it's not. (With the provision that you provide the source code when you provide a binary - this obviously doesn't apply to PHP, unless you're using something freaky like ioncube. No-one's suggesting that.)

You could argue that locking up apps behind a paywall's wrong. The thing you need to remember here is that the people interested in this standard are all part of the community, and recognise the benefits of sharing code. It wouldn't surprise me one bit if app stores when implemented install code for end users with a payment to support their development, but will also provide the source code for developers who want to build on the work free of charge. Of course, this is up to the people running the store. All this group seeks to do is define standards for the interoperability of stores. Individual store policies are up to whoever's running them.

It's possible that I really

dgtlmoon's picture

It's possible that I really don't understand your reasoning behind this project, or perhaps that there is some underlying commercial/corporate angle to this that I just cant figure out.

Ok so, what I and many Drupal practitioners offer is a service, not a product, I think this is where your understanding and mine differs. Although you could consider a module to be a 'product'

Are all the apps on the store entirely opensource? it would be very awesome to have a much cleaner way of installing new modules

The way I understand it, is that GPL means the software is free (not chained, tied, walled etc) and able to be distributed, not necessarily $free$, if you are considering selling non-GPL-non-free-paid-only modules then your workflow should also be expanded to consider support arrangements with the author somehow (feedback mechanisms etc)

I guess to me, deviating from the GPL sounds like you are biting the hand that feeds you, you are ofcourse entirely free to develop your own venture.

I'll try to answer your

z.stolar's picture

I'll try to answer your concerns (and will try to repeat any of Rupert's words :) ):

Drupal is constantly challenged for being a programmers-only platform. I showed some administration screens to a prospect a couple of days ago, and instead of saying "Wow! So many options!", he said "Oh boy... So many options..." :)
D7 has brought many usability improvements, but work is not done yet. There are many aspects to it, and one of them is extending a Drupal site with new capabilities, without having to bother with downloading, reviewing and configuring a module, or worst - few modules. Not to mention that in some cases there's always a need to write some glue code.
A workflow which imitates adding applications in mobile platforms (i.e., Android, iOS) is a natural evolution: people are used to it, it's easy, it's quick. An easy "add app" workflow will bring more people to use Drupal in the future.

Regarding GPL issue - this should not be different than anything we're doing right now. The only thing that changes is how the app gets to your website. The question of whether a code is under GPL or not is relevant everyday for us, not only when apps will be out there. If we're developing a module for a client, we will always convince them to release the code as open source, because we understand the value of releasing it both for the client and for us.
This rule is not different when serving apps:

  • An app which is downloaded to the website should contain it's source code (regardless of whether it's being sold or not)
  • An app can be sold for use on a hosted service (such as Gardens and SubHub, or hosted services of other products), in which case the source code may be kept proprietary.
  • By having the app as open source, it can be improved and extended by others.

App stores, and the whole apps model, will create different financial models for developers and companies, but that's not so bad, is it?

Apps are likely to be here to stay

yautja_cetanu's picture

One location I quite like is this: http://community.aegirproject.org/handbook/open-app-standard-draft

I spoke to some people at Koumbit (who are heavily involved with the aegirproject above) and they are very much into the spirit of opensource (If you look at what they have done with Aegir and SaaS I think you can see this really clearly). But are interested in apps. I found my developers were initially very hostile to the idea of making an app but upon further investigation it looks like something that could be pretty interesting for everyone.

The main big issue with apps making money is they exploit theWeb services loophole in GPL v2. If Drupal had been based on AGPL for example then it would change things. However, even Dries is very much in favour of this: http://buytaert.net/long-live-the-web-services-loophole. I've heard richard stallman hates this loophole but linus torvalds is more of a fan of it. So its a complicated issue that simply has no simple answer in literally the whole opensource community.

The question now though is this. We know that the creator of Dries is in favour of the web services loophole. We know it is legally possible for someone to take views and make a ton of money off of it. So as a community do we let someone from outside our community make the first app store? Or do we as a community do it properly in a way that keeps everyone happy and do it first? As an individual developer you can merely complain. Or you can help draft the open app standard to make sure all your work is actually protected. (Our plan is to release apps, but also release the sourcecode from apps. The way I see it the kind of person who would use subhub and install an easy to use app is someone who wouldn't want to go through the hassle setting up a site themselves. Also subhub provide essentially free hosting and so present really interesting ways of monetising our code that doesn't hurt the customer (Such as imposing limits on the number of people they can have in a CRM)).

Regarding the "commercial/corporate" angle that you can't figure out. Well the information is available. You can see through drupal.org that rupertj is part of subhub and they are very open and honest about their angle. You can go onto IRC and speak to them (as we have) if you're uncomfortable about stuff (as we were). You can also see all the other commercial entities involved, from Phase2, Koumbit, Acquia and here we see linovate. None of them hide their commercial intent and all of them are getting involved in openly discussing the best way to go forward with things.

Where does the GPL even come into this?

ergonlogic's picture

Where does the GPL even come into this? The idea behind Apps is really a packaging and deployment mechanism. They are basically intended to make for a seamless installation experience, from within a client's site (rather than have to FTP, drush dl, &c.) At this point, Apps are just Features (as in features.module), and thus modules, with some additional meta-data. Since PHP is an interpreted language, the source code is, of course, included.

So far, the business models being proposed behind Apps basically breakdown into three categories:

  • Support
  • Customization
  • 3rd-party web-services integration

For anyone interested, I strongly recommend viewing the DrupalCon session that addresses these issues: Taking Inventory ofDrupal Products and App Stores

Particularly insightful, especially at this stage of the process, is the following quote from Moshe Weitzman:

... It's a foregone conclusion that there's going to be apps stores for Drupal [...] If you agree with that premise, then you want app stores to be good for Drupal [...] and to be done responsibly [...] All of us are making an open apps standard. That's something that Apple didn't feel the need to do. That's something that Google didn't feel the need to do. Lots of app stores never have an open standard. I think you have evidence of the Drupal community doing it in a Drupal way, already. If we can keep talking about it and keep doing it in a Drupal way, then it's going to come out strong in the end.

Right on

jwalpole's picture

@ergonlogic - your assessment of the GPL implications and business models at this stage are right on the mark. Also, thanks for sharing the Moshe quote. It is absolutely the attitude that those of us working on the standard and apps module are embracing: make it work for the community, the companies, the developers and Drupal at the same time.

@konforti - thanks for picking up a part of the effort

Just to clarify

rlnorthcutt's picture

What is the actual "file" being purchased? A module? Feature? Distro? All of the above? In these cases, then the GPL nature means that purchase includes rights to modify and redistribute. That would make those apps less financially viable... sell it for $5, and I can buy it and immediately offer it for sale for $3... etc.

If the "file" is some type of integration module or code for interacting with a 3rd party service (which may or may not be built with GPL code), then the financial value is retained via the "service loophole" above.

Also - is this assuming that the platform for the app would be a drupal site itself?

ron

PS just to be clear - the financial value of a product <> the actual value... it can be expensive & worthless or free & priceless or something in between

Peace, Compassion, Prosperity

What is the actual "file"

z.stolar's picture

What is the actual "file" being purchased?

The downloaded app is composed of several files, similar to a Feature (see http://drupal.org/project/features).
Yes, it is GPL, and downloading it means you can resell it. Whether you do it or not probably relies more on your business objectives than on your technological skills.

For Linnovate, setting up a store and selling apps for a low fee is part of a business plan (and this may change). If it is the same for you, then you are welcome to use the same building blocks (since we're also in the process of creating an app store distro), and eventually the same apps.
I think the difference between stores will be ease of use, trust, customer loyalty, additional services, updates, richness of apps and more.

We're living in an open source world, and the fear of working hard for someone else to sell your work is irrelevant.

I believe that non-techy clients wouldn't mind paying a couple of $ for having a feature on their website which would have cost them dozens of times more if a developer was involved.

Blender App Store

darKoram's picture

This looks like a fantastic initiative. Am i to understand that the core of this app would be portable to any openSource add-ons store? To respond to the comment that started this thread, blender is a great tool, but right now it services the novice community much better than the professional production team. In our case, the "apps" would be python scripts that make workflow more efficient or add new functionality.

Lots of production teams try to use blender, but some of them get frustrated for lack of polish, and plug-n-playability of features. Recently, leaders at blender have discussed starting an app store that would
- improve the quality of addons (apps)
- encourage a "polish" phase for apps
- make it easier for people to find great apps
- reward developers financially, allowing them to spend more time making great apps

It's quite likely that after an app becomes popular, it will be incorporated into Blender proper since the community culture is strongly open source. There are ways to "Strongly encourage" this behaviour with a profit-sharing structure between app developer and host-open-source-project. Are there any examples of this module in action to check out?

darKoram

It relies heavily on Drupal's

z.stolar's picture

It relies heavily on Drupal's way of installing an app/feature/module, but it does incorporates the basics of any apps store (browse, authenticate, identify clients, buy/sell). However, I think it would be a bit pretentious to think this app store can sell generic apps for all open source projects :)

Is App Store limited to Drupal Apps?

pjonnala's picture

Hi,

Is the App Store functionality limited to just Drupal Apps, or can the system be used for other apps - such as web apps, mobile apps, android apps, etc.?

Thanks in advance,

-PK

Drupal App Store BoF DrupalCamp London 2013

dahacouk's picture

We just had a BoF at DrupalCamp London 2013 on the "Drupal App Store" after the subject was brought up by Robert Douglass in his keynote. See http://groups.drupal.org/node/286343