It is planned to develop a repository for TYPOlight extensions. The requirements were first discussed at the meeting of Würzburg in a developer workshop. The workshop summary and the package specification draft are available now in the WIKI.

Your comments are welcome.

Wonderful work, Peter. Thank you!

I do have a question - during your discussions, did anyone ask how limited vs. full features were to be implemented (as in the case of a demo package)? Will Leo be providing a library to help us enforce activation key restrictions on certain features? I would assume we could copy the functionality of the live update key as Leo created it, but obviously we will need a more granular approach for demo versions.

Thanks for your hard work, gentlemen!

Fred

Fred,

Demo versions / restricted features

There was no discussion about how exactly demo versions would work, but if you look into the package specification, the "classification" element has a type "demo".

It is assumed that for commercial extensions the vendor would run both, a shop where the customer can buy a download key, plus a SOAP service to answer file requests. When you get a request without valid download key, you would send the demo version files, and for a request with valid download token you would send the unrestricted version.

For even more fine granulated control you could send different file sets depending on what features you sold for a individual download key.

Live update

If the user has a valid live update token, not only the core will be updated automatically, but also all extensions (in dependency order). There is nothing special you have to do as commercial extension provider, the live update will work with your SOAP file service.

Aside from live update there will also be the option to individually upgrade each installed extension by clicking an update button.

Custom SOAP service

We will provide a sample service which is basically a stripped down version of the repositories SOAP service. You will have to implement your own download key validation of course, but that should be no issue for developers with php knowledge good enough to make a commercial extension

Hi Acenes,

I just read your package specifications, it sounds really good!
Just a suggestion, don't you think it would be better to embed description and releasenotes into CDATA section ?

Code:

<description language="en">
<![CDATA["This<br/>is<br/>my<br/>description"]]>
</description>

Unless there is a tool to create the package.xml and thus validate xml.
In this case we must forget what I just said.

Hi Cyril,

Andreas Schempp was working on a tool to create packages for templates, and we discussed if he could extend it to a more general package creation tool for the extension repository. He might be giving us some information later when more details are available.

Thanks for your answer, it still sounds better!

Sounds really great!
Any informations of a cost for vendor to publish commercial extentions?
Will the SOAP module for vendors will be commercial?

++

s-mart:

Any informations of a cost for vendor to publish commercial extentions?
Will the SOAP module for vendors will be commercial?

This question was not yet discussed, and touches a sensitive area: How will money resulting from community efforts be managed and spend? Since Leo is starting to build up community resources, also a kind of formal organization for it will have to take place.

But BTT: I assume there will be some (very affordable) fee for commercial extensions, such as a monthly amount which the vendor can declare as 'advertising cost' and helps us cover community expenses such as servers, organization etc.. I don't think there would be an additional fee for the SOAP module however.

All this is subject to my wild guesses ATM though

Hi acenes, thanks for answering.
I'll wait for some more infos on that.

++

santiago

Just my 2 cents,

I would be happy to pay a module listing fee as well as a small percentage in the same way that ebay does. I would say study the ebay business model and learn from it. It works. Paying a fee of some sort to initially list your module for sale would allocate funds for the resources it takes to host the extension repository, as well as the small percentage of sales to act an the annuity income to keep the repository fiscally stable.

If I were to submit a module to the repository, here is what I would expect to get (and would happily pay for)

- Exposure/Traffic to my projects that are listed
- Permission to collect credit card payments and/or e-check/ach processing
- The ability to market to existing customers via email
- A 3rd-party Typolight module vendor certification that I could display on my own site that would indicate that a certain level of quality is assured in modules that are listed, and that a certain level of customer satisfaction is maintained
- A way to facilitate a certain level of support a la a micro forum for each project under my company account in the repository
- Access to the SOAP service
- Perhaps others I can't think of

The point I'm trying to make is that there are obvious ways to encourage people to pay to use the repository, all leading back to a mutually beneficial relationship between 3rd party developers and the Typolight project. We get the convenience of the repository and it's e-commerce tools, exposure, credibility, and a good way maintain customer satisfaction via the micro forum, and Typolight generates revenue.

Thoughts?

Fred

Here are my 2 cents,

I also would be happy to pay a fee for having access to the official typolight listing.
I think it's one of the best ways to give the project ressource to pay hosting, time spent to maintain, ...

I think a small pourcentage on each commercial module sold (for example 5 %) would give the project some ressource to get stronger, to innovate and maybe could bring leo enough revenues to live developping typolight.

To do this, it would be needed to give vendors the ability to sell their extentions, themes,... directly from typolight main website.

I think of the kind of model apple will use to sell iphone apps in the future.

Santiago

Although I'm not an extension developer, it seems like some good points have been made here in regard to using the main TL extension repository for both open-source / free and commercial extensions. Unless I misunderstand things, it sounds like selling commercial extensions requires that the developer do some coding and API connecting to sell through the main TL repository. I like Fred's idea of just having it all handled through one repository and taking a percentage of each sale for Leo or "the team".

The "problem" of selling things through the main TL repository are not really technical but from the law side of things. I think it would be quite complicated to set up a construct where somebody is selling things through the extension repository but Leo would not become the vendor and thus reliable for the product warranty. Can You see where I am aiming at?

I think I remember that there were ideas that a commercial developer would sell ID's (kind of like the update-IDs) on his own website and these IDs can then be used from the main TL repository to install and update the respective extension. But Peter, please correct me if I am wrong...

I don't know how this is handled somewhere else but in my country if somebody sells a product, he is in first place responsible for it, e.g. a consumer having issues need not travel himself down through the whole supply chain to find out who to blame or sue, its the job of the seller to fulfill the contract or refund money or whatever. But the resellers take good money for that service in turn, usual reseller profit is about 30 - 35% for IT stuff such as software or hardware.

That's not exactly what we were looking for in first place, and why I came up with a model where the repository is something like business directory where you can find the product, but then buy it directly from the "manufacturer".

I do understand your issues about running a shop and hassling with credit cards etc, especially for somebody running this as a secondary business. However basically you don't even need to run your own shop. The easiest thing to do is create a PayPal account and point your repository shop link to it. A similar service that I found very professional (as consumer, I'm not selling with them myself) is http://www.cleverbridge.com.

Another reason why you might want the repository to sell your products could be reputation. But much better than "hiding" behind the repository shop is creating a good product and providing good service. Doing so will bring you good reviews in the repository which if far more important for the business that how exactly the payment process works.

Don't get me wrong, I would not exclude that the repository could some day come up with a payment/shop of it's own, but for the time being we don't have the financial and human resources to do it in release 1.

For those fearing the SOAP service: There will be sample implementations where you don't have to fiddle with any technical details other than how you want to verify download tokens. Even for that when some brilliant designer wants to sell his template but has no idea about PHP there are developers in the community happy to help. Maybe we will come up with a service to also host commercial files, but right now we should try to keep it simple and get a first version off ground.

@Fab

At least in the U.S., anyone listing has to indemnify (or hold harmless) the service from any issues relating to customer service for the 3rd party extensions (hence them being 3rd-party) This is how any site which facilitates commerce between two parties not affiliated with the company providing the service works.

I agree both free and for-sale extensions should be made available, but that those which are for sale must be from an approved vendor that has gone through some sort of process to be approved to use the service to sell their extensions.

My concern in not utilizing the SOAP service, it's more from the standpoint that I don't have a website currently which can host the SOAP service on my own. I may choose to go that way at some point, but why reinvent the wheel? If the cost is reasonable, I'm happy to pay to use the service provided by the extension repository.

Great dialogue gents!

Fred