Payment for the Eclipse Marketplace

Imagine you are searching for a new Eclipse plug-in to help you with the technology stack of that new project of yours. Where do you go hunting? Google, followed by searching for the update site URL on some vendor website? That long list of known sites already configured in your IDE or stashed away in your bookmarks? Or do you just hit the Eclipse Marketplace?

Our own numbers for UML Lab paint a very clear picture: with more than 50% of all downloads, the Eclipse Marketplace is by far our most popular distribution channel (with direct update site installs and standalone RCP downloads making up the rest). What’s more, at over 1500 listed solutions and nearly 4.5 million installs, it is the place for Eclipse users to find new plug-ins and for Eclipse vendors and member companies to be found. And with the Eclipse Marketplace Client putting all that at your fingertips right in the IDE, it’s built for convenience.

But what if you actually want to buy a commercial plug-in? The Marketplace is great for getting free plug-ins in one place and has come a long way in consolidating the ecosystem of previously scattered update sites. It’s also great for tool vendors to create awareness for their products. When it comes to buying those products though, it’s pretty much back to pre-Marketplace times: Eclipse users have to switch between, the Eclipse Marketplace Client, individual shops, update sites, registration and license emails, download links and websites of Eclipse vendors just to try, buy and use Eclipse with different plug-ins.

We think it’s time to take the Eclipse Marketplace to the next level: Let’s turn it into a true marketplace for all Eclipse plug-ins by adding a payment option for tool vendors. Let’s offer the same awesome, integrated user experience to buyers of commercial solutions. In fact, let’s make the Marketplace what it was intended to be from the start. From the original announcement of the Eclipse Plugin Central (EPIC), the Marketplace’s predecessor, by Instantiations, Genuitec and Innoopract:

Our mission is to support the growth of the Eclipse community by helping developers locate, evaluate, and acquire plugins that can help them deliver their projects faster, better and cheaper. At the same time we provide software publishers with a means to increase product sales through this innovative new distribution channel. […]

Our goal is to:
* Be the one-stop destination for Eclipse plugins and information
* Provide useful, concise, topical and relevant information
* Simplify plugin location and purchasing for Eclipse developers
* Help plugin publishers increase customer reach and awareness
* Contribute to the growth and success of the Eclipse ecosystem
[…] A complete eCommerce marketplace will be added over time.

So if that was the plan from the start, why doesn’t the Marketplace already offer this? Well, because it turns out that creating and running an international e-commerce platform that safely and securely connects users and vendors from all around the world is far from easy. Such a platform has to deal with

  • Payment Options (credit card, wire transfer, …)
  • Certification of payment components (required by financial institutions)
  • Currencies (USD, EUR)
  • Multiple vendor bank accounts (per solution, country, …)
  • Legal, Contracting, Invoicing
  • Taxes (Sales Tax/VAT, ID check, VAT reversed, per Country, State, …)
  • Consumer Rights (Cancellation in EU, …)
  • Non-Payment Risk (payment defaults)
  • Licensing Models (Trials, Personal / Volume, Annual Licenses, Pay-per-Use, …)
  • License Configuration (Initial Setup, Activation, Deactivation, Recovery, …)

to name just a few of the challenges. Unfortunately, the Eclipse Foundation itself does not have the manpower or financial resources for this. And it can’t deal with the legal and fiscal complexity, let alone take the financial risk of operating such an international payment solution. However, we believe that this platform is necessary to really make Eclipse the open and innovative tool platform for open-source and commercial development tools it is meant to be.

The Solution: An Open Marketplace Payment Platform

The solution we propose is to extend the Marketplace Client (MPC) to offer an open payment platform that online shop owners and payment service providers can build on. The client will be extended to show a Buy button and basic pricing information. An open payment API will act as a bridge between the Marketplace Client and 3rd-party payment implementations, allowing Eclipse vendors to develop and offer payment solutions. The Eclipse Foundation doesn’t have to provide payment itself and adopters can offer payment tailored to their business. Every Eclipse vendor will be enabled to bridge the gap between closed-source payment and licensing solutions and the open Eclipse Client.

To fit into the Eclipse ecosystem successfully, the proposed payment platform has to

  • Be vendor-neutral and open
  • Be a small effort for tool / solution vendors to integrate or use
  • Provide payment services largely independent from

Keeping payment infrastructure (a) independent from the marketplace server and (b) based on public Eclipse Marketplace API not only solves the problem of the Eclipse Foundation being unable to provide payment services. It also means simpler integration with the existing marketplace ecosystem. For one, because the existing closed-source Eclipse marketplace server does not need to be changed. But more importantly, it ensures open access to the Eclipse community with closed-source payment and licensing software already in use by Eclipse vendors. The Eclipse Marketplace will be kept 100% open-source.

Separating marketplace catalogs and payment services means that a point of integration is needed. The Marketplace Client is the obvious choice for this. It’s already where the information needs to end up – to put pricing information and purchase options right at the user’s fingertips. It’s also uniquely prepared to integrate payment services technically. Client/Server communication infrastructure is already in place, allowing implementation of additional payment communication without much overhead. And the possibility to directly interface with the MPC’s P2-driven provisioning system allows for a seamless integration of related services like zero-configuration license checkout to have any purchased product ready to use directly after installation.

Payment API

Technologically, the API required to interact with the Marketplace can be kept very light-weight. The real challenges mentioned earlier lie behind that API and are responsibilities of the providers offering the payment services.

In order to integrate their solutions, payment providers only need to implement a simple PaymentModule interface providing basic actions to discover prices and interact with their shopping carts. Payment modules are contributed to the Marketplace Client by plug-ins and registered with a central PaymentService in the MPC via extension point. The PaymentService manages the registered PaymentModules, delegating work like requesting an offer() for price details or triggering a purchase() of specific Marketplace entries to the PaymentModule responsible for it.

Whenever the Marketplace Client lists solutions, e.g. showing popular entries or search results, it receives solution data from the server as Nodes. For each node, the MPC wizard checks asynchronously if a Buy button should be shown. The PaymentService tries to find a PaymentModule to handle that node and if a module is found, its offer() method is consulted to retrieve pricing information for the entry. If pricing information is available, a Buy button is added to the solution entry, by default showing just the price and a generic shopping cart icon. Icon and button text can be customized with an ILabelProvider.

Clicking the Buy button will result in a call to the purchase() hook of the corresponding PaymentModule. This will typically put the entry into a shopping cart and show that cart in a separate editor inside Eclipse, suspending the MPC wizard until the user revisits it by e.g. choosing to select more items or completing checkout. Helper methods are provided to assist with suspending and resuming the MPC.

Basic information about the current state of a PaymentModule’s shopping cart can be retrieved using the module’s getSession() method. The MPC wizard will use this for example to determine all carts with pending purchases and reopen them using the checkout() method before proceeding to the feature selection and installation stage, giving users a chance to complete their purchases.

If no installed PaymentModule is found for a Marketplace entry, the PaymentService supports discovery and installation of additional modules using an URL-based query scheme with a list of discovery URLs distributed with the Marketplace Client. Newly discovered modules will be shown in the MPC wizard as a greyed-out (but not deactivated) Buy button. Clicking the button will trigger installation of the discovered payment plug-in before continuing regular payment workflow. This is expected to work without restarting Eclipse.

Plans also include an open license configuration interface that can be implemented by commercial tools to integrate their license management system with the payment API. If present, the interface will be called after tool installation and purchase with details of the transaction. This can be used to e.g. support automatic retrieval and configuration of the purchased license to get the product ready for immediate use.

For more details about the proposed payment API implementation check out our preliminary codebase at GitHub.

Our Contribution

As tool developers, we are interested in making it as easy as possible for prospective customers to find, use and buy our modeling tools.

We started this company because we wanted to create great UML tools for Eclipse. We certainly did not want to build an online shop. We had been surprised when we found out that none of the existing shop systems matched our light-weight, easy-to-use requirements.

Today, we have a working – and successful – shop solution in place for our current products, with the Marketplace working as an additional marketing channel for us. But presenting and marketing our products is still an ongoing challenge, making every product release more expensive and more tedious than necessary. And by now, we’ve also learned a lot more about how differently individual people use our tools, requiring very different feature subsets for very different use cases, some of which we never even would have imagined. With that in mind, we are looking forward to widening our product portfolio and at the same time offering more and smaller tools with more flexible licensing options at lower prices.

At this point, we could just soldier on and put yet more resources into adapting our own, isolated shop and other sales and marketing instruments, which would still end up not really integrated into the Eclipse user experience – putting unnecessary burdens on our customers and ourselves. Instead, we consider these resources better spent on an integrated platform that benefits the whole Eclipse ecosystem - users, developers and vendors alike.

That’s why we are looking forward to providing a payment solution to the Marketplace Client and helping establish it as the one-stop place for “Eclipse shopping”. We will contribute the implementation for the open MPC payment infrastructure. On top, we started developing a complete MPC payment service and eCommerce system which we will provide openly to every single Eclipse vendor – without any fixed charge. Our goal is to lower market entry barriers for new Eclipse tools, start-ups and vendors. At no fixed costs and very low transaction costs, offering even very small or low-cost tools will become feasible.

We believe in a richer ecosystem with more and better tools and huge benefits for commercial and open source solutions alike: commercial tool vendors benefit from an effective additional sales channel at low costs, while open-source projects and developers can be supported with a project-based donation option. Ultimately, the whole Eclipse ecosystem will benefit from more companies and developers investing more resources into Eclipse.

With a number of confirmed partners already on board and very positive feedback from many more community members at EclipseCon, we are looking forward to a successful launch this fall. If you have a commercial solution that you are interested in selling via the Eclipse Marketplace, have specific requirements that you want us to consider or just want to provide feedback, please contact me at