Extension Store

[Daniel Peraza]

Hi guys. I would like to propose the construction of an official extension store, much like the App Store or Google Play, so everybody can download sercure, certified & tested extensions. This store should be accessible right from every Joomla installation through its admin area, and I think it can be another way for the team to monetize the project, raising funds to continue developing this great CMS. It would be awesome if the Store could offer technical information on extension performance or security issues.

What do you think about this?

[Donald Gilbert]

It's a great idea, but monetizing it to pay for development of the CMS will never fly for the simple fact that there are those who believe that paying for code isn't something that Joomla! As a project should be doing. 

But, from a technical standpoint it's a great idea. Joomla could set up its own Satis server to act as the code repository and search engine for a customized composer based installer. That way, extensions could actually handle dependencies in a sane matter. There's so much to work from in PHP land right now that it's almost ridiculous how many examples we could use as our guide. 

—
Sent from Mailbox for iPhone

On Sat, May 4, 2013 at 4:09 PM, Daniel Peraza <daniel...@gmail.com> wrote:

Hi guys. I would like to propose the construction of an official extension store, much like the App Store or Google Play, so everybody can download sercure, certified & tested extensions. This store should be accessible right from every Joomla installation through its admin area, and I think it can be another way for the team to monetize the project, raising funds to continue developing this great CMS. It would be awesome if the Store could offer technical information on extension performance or security issues.

What do you think about this?

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[kisswebdesign]

Perhaps if it were done in a way that implents jed in the backend it would be OK, after all there are already commercial extensions on jed without it causing issues.

Listing extensions is free, commercial extensions could pay a nominal (ie small) listing fee? Or if Joomla / OSM acts as payment processor they could take a tiny percentage to cover costs (and maybe make a tiny profit).
By acting as payment processor for so many (so much money), any cost savings on fees could mean that the commercial devs receive the same amount per sale as they currently do - even after paying the listing and/or processing fee.

Of course jed would carry on as now, so it is not necessary for backend access to explore and discover the extensions. And individual devs can still take payment on their own site as they do now.

There are, of course, lots of things to consider - especially regarding payment processing.

Another option would be for each commercial developer to issue a download (licence) key, upon payment completion that would give authorised installation of the extension through the 'app store' - as well as allowing customers to download their product and install it themselves.

Perhaps this is a step too far at the moment, as there will undoubtedly be objections to a change like this. Maybe it is something that could be developed along with 3rd party devs for the next incarnation of the CMS (joomla!next or whatever). There are already extension managers that work really well for individual developers extensions, that knowledge, experience and expertise is worth capturing. Because whatever evolution the CMS goes through, the 3rd party devs are key to its success - just as they are now.

Disclaimer: This is just me thinking out loud here, and typing on my phone at 11 on a Saturday night. Some alcohol may have been consumed.

[Amy Stephen]

On Sat, May 4, 2013 at 4:26 PM, Donald Gilbert <dilber...@gmail.com> wrote:

It's a great idea, but monetizing it to pay for development of the CMS will never fly for the simple fact that there are those who believe that paying for code isn't something that Joomla! As a project should be doing.

There are those who feel it's a very good use of funds, too. =)

[Donald Gilbert]

Oh yes. :) I might know one or two. lol

—
Sent from Mailbox for iPhone

[Nick Savov]

Hi Daniel,

It's one of the overall project goals :)
http://community.joomla.org/blogs/leadership/1730-2013-overall-project-goals.html

My view is that it's best to have a distributed payment solution and
provide API to allow developers to handle the transactions with their
payment gateways. This way Joomla won't have to concerned about handling
refunds, billing issues, etc, etc.

Are you interested in helping to code an AppStore-like feature? If you
are, I'd love to get you connected with others that are interested and
also help you through the submission process.

Kind regards,
Nick

[Eric Fernance]

Nick,

Can I put my hand up for more info on getting involved in this? (sorry to resurrect an old thread, I'm just a bit behind on the group!)

I have lost a few clients to Wordpress lately due to this exact sort of functionality so would be interested in getting involved in this area.

Eric.

[Paul Orwig]

Hi Eric,

Thanks for putting your hand up to help with this! Right now, progress on the app store goal is being delayed because of me. I volunteered to write a blog that will ask for volunteers to join a working group to research and study the issues and help draft initial requirements.

I'm sorry I have been meaning to do that for some time, but I just haven't found the time for it yet. Please be a little more patient and keep an eye out for that blog.

Thanks,

paul

[Nikolaos K. Dionysopoulos]

Nick,

Excuse me if I'm being skeptic, but the way I understand your proposal the developer is responsible for:

1. Have their own subscription / purchase management system
2. Accepting transactions with their own payment gateways
3. Handle billing, refunds, cancellations and whatnot including but not limited to invoicing, accounting and taxation
4. Handle support, through a system that they have to select, maintain and integrate on their site
5. Pay a commission to the Joomla! App Store

Items 1 through 4 are already necessary to run a Joomla! extensions business. Item #5 is not necessary – we solicit business through our own means and JED, by consuming a substantial amount of time to ensure compliance with the Draconian rules of the JED. As a business owner I do not see the benefit of having to wear the cost on #5. What's even worse is that OSM, being a non-profit in the US, will sure as heck not issue me an invoice for the money I spend for item #5. This means that as far as the tax authorities are concerned I have this money in my bank and get taxed accordingly.

I'll pull off an example. Let's say you have a business in Greece with a now flat taxation rate of 33% and a VAT of 23%. Let's assume that JED requires a 30% commission, like the Apple App Store. Let's say that I'm making a 40 Euro sale (32.52 EUR net value plus 7.48 EUR VAT). This translates to the following expenses:

• 30% commission to Joomla! App Store: 12 EUR
• 23% VAT: 7.48 EUR
• 2.9% + 0.28 EUR transaction fee: 1.44 EUR
• 33% taxation on the net price (32.52): 10.73 EUR

Total expenses: 31.65 EUR. This leaves me with 8.35 EUR for a full year's service of updates and support. The only way I can survive this is offering no support or hiking the price up. In either case I am going to lose clients. You see, 40 EUR is expensive and clients expect a quality of service in par with what they paid. But when Joomla! App Store cuts my profit (and income) by 60% how am I supposed to offer this service?

This is nuts! This is the best plan to drive Joomla! extension developers out of business! If you want my business to give you a commission you have to give me something back. Exposure?It's definitely NOT worth a 60 (SIXTY!) PERCENT reduction in my net profit. What should I do with more exposure if it costs me my business and my livelihood? If you want me to pay a commission handle items 1 through 3 (payments, subscription management, invoicing, accounting, refunds and cancellations) yourself. And you have to pay me against an reverse charge invoice, like Google does. Or have a zero commission – which means that you've just reinvented JED, plus a "Buy now" button. In any other case your App Store proposition sounds like a bad joke.

Yours truly,

A former business consultant.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Amy Stephen]

Wow! Not sure how you got any of that from Nick's comments. The best defense is a good offense?

Nic - let's always start these discussions with appreciation of the value the community has provided to commercial developers in that we have collectively helped build a market and provided  advertising, both of which have real value, and that this has been done at no charge to commercial developers for years. Just because it's important to make certain all the volunteers feel good about their involvement and so that it doesn't feel like anyone is taken advantage of. I personally know you and I know you feel that way and I know you also contribute in big ways to the community.

Personally, I'd rather *not* see the project engage in taking money from the community on behalf of extension developers. For so many reasons, one reason being we might see rules become even more stringent and the delays for listing even longer.

But, before either one of us launch a full scale assault on the possibility that an idea might exist somewhere, we might want to wait for actual information before responding further.

Relax, mister! I think it will be okay.

[Eric Fernance]

Hey Paul,

No sweat!  I think all of us struggle on the time factor!

I'll watch out for it!

Eric.

[Eric Fernance]

Personally, I'd rather *not* see the project engage in taking money from the community on behalf of extension developers. For so many reasons, one reason being we might see rules become even more stringent and the delays for listing even longer. 

Ironically, payments is probably one area though where an app store could really add value to developers.  I am in Australia and use Paypal for payments, it's easy and for me it makes sense.  There are regularly countries and currencies though that are not supported by Paypal or problematic to use with Paypal.  Just recently someone told me that it won't handle the Indian Rupee and half a dozen people have told me that in Brazil Paypal is one of the least popular options.

A Joomla! app store that handled payments would theoretically mean that we could offer a choice of truly international payment options as there would theoretically be international developers able to work with all the local payment gateways.  Want PaySeguro (https://pagseguro.uol.com.br/#rmcl) as a couple of international clients have wanted???  ...I'm sure there are Brazilian developers that are working with that gateway.

Eric.

[Paul Orwig]

I think some really good diverse insights have been shared here and that's really helpful. I am certain that whatever we might come up with won't please everyone, but hopefully we will find a good fair balance. As with everything, we should always be looking for ways to improve it over time.

My personal feeling is the primary goal for the app store should be to make it a lot easier to search for and install extensions. After that, I think we want to create a system that is fair and acceptable to extension developers (free and commercial) and easy for the project to manage (including the possibility of outsourcing some parts). If we can do all that and also bring in some more revenue for the project (understand that JED traffic would likely decrease after an app store launch, and Google ads on the JED are one of the project's major revenue sources), then that would be even better.

But there are definitely a lot of factors to consider, and that's a key part of what that initial working group will focus on.

Thanks,

paul

[Nicholas K. Dionysopoulos]

Eric: You are very correct on all points. FWIW we've implemented a little over 40 payment methods, including PagSeguro. Most of them are very localized solutions. If Joomla! wants our code or experience consider ourselves volunteered. 

Amy: I use "their" an it's perceived as a problem. I use use "your" it's the same. Pardon my lack of adequate English knowledge but I am left with his, her, our. The former two will cause complaints for gender bias, the latter is incapable of separating the identities of two groups of people having a different opinion. Should I start posting in Greek instead where "your" is not considered problematic?

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

[Mike Hamanaka]

Extension store or app store is too vague.

The specific problems of difficulty in researching extensions everywhere on the internet, qualifying, sourcing, purchasing understanding thr licensing, support packages, installing, maintaining/updating, configuring Joomla extensions and other such related communication or noise about extensions or distros.

Certainly more marketplaces are better then less for the end users.

Wouldn't it be the best to start with, to have something like the VEL wiki, but as comprehensive as that CCK comparison spreadsheet as a starting point for everyone to collectively start organizing and sharing the million little bits of information about extensions.  Community could build on that.

Mike Hamanaka

Website Production 

Vertualize.com

[Amy Stephen]

On Thursday, May 23, 2013 12:39:15 AM UTC-5, Nicholas Dionysopoulos wrote:

Should I start posting in Greek instead where "your" is not considered problematic?

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

Sent from my iPhone. Please excuse my brevity. 

lol - Thanks for the giggle. =)

Eric - I have no doubt having the project take care of payments on behalf of commercial developers would be something many would find helpful. Striking just the right balance to support both the volunteerism and commercial aspects of our community is always important and challenging. 

[Beat]

Just FYI to avoid projecting too far in the wrong direction: Accepting money on behalf a third party for more than an overall total amounts of roughly a few thousands is not allowed by regular Visa/Mastercard contracts and more importantly by international anti-money-laundering regulations and banking laws.

If you want to do that, you either have to get a bank license or to get a license as a financial intermediary which is subject to heavy cost and heavy workload. Plus you would need to have huge turnovers with Visa and MasterCard and lengthy negotiations with them before that they accept that. Not counting either international accounting overhead. So basically, only very large corporations can afford that.

I have checked that with a large auditing firm and got a written answer for exactly that case of "making life easier to others" model from an official anti-money-laundering organization when we wanted to offer an easy life for CBSubs users that asked for that. So not just my opinion, but giving the results of the expensive check that I did here back to the community for free.

Unless things changed in the last couple of years, which I greatly doubt given the grip on tax frauds, the only way is that each extension developers does the cashing-in himself, staying subject to regular business (non banking/financial entity) laws.

As usual, IANAL, take your own advices, I'm here just sharing the results of the one I already paid for.

Best Regards,

Beat

http://www.joomlapolis.com/

[Paul Orwig]

Hi Beat,

Thank you for sharing what you learned, that's really helpful!

Best regards,

paul

[Nick Savov]

Hi Nicholas,

I didn't have #5 in mind ;) I figure it should be free in the same way
that the JED is free and I'd rather not have Joomla handle #1-4, which
should be the responsibility of the developers, in my opinion.

Since developers are the ones that would be profitting from an AppStore
using this approach, I'd hope that many of them will contribute back to
Joomla in a significant way to improve Joomla for everyone else,
themselves, and their businesses.

Hope this clarification helps!

Cheers,
Nick

>
> Nick,
>
> Excuse me if I'm being skeptic, but the way I understand your proposal the
> developer is responsible for:
>
> Have their own subscription / purchase management system
> Accepting transactions with their own payment gateways
> Handle billing, refunds, cancellations and whatnot including but not
> limited to invoicing, accounting and taxation
> Handle support, through a system that they have to select, maintain and
> integrate on their site
> Pay a commission to the Joomla! App Store
>
> Items 1 through 4 are already necessary to run a Joomla! extensions

> business. Item #5 is not necessary - we solicit business through our own

> does. Or have a zero commission - which means that you've just reinvented

> JED, plus a "Buy now" button. In any other case your App Store proposition
> sounds like a bad joke.
>
> Yours truly,
>
> A former business consultant.
>
> Nicholas K. Dionysopoulos
> Email: niko...@gmail.com
> Blog: www.dionysopoulos.me/blog
>

[Nick Savov]

Awesome! Thanks for volunteering, Nicholas! :)

[Nikolaos K. Dionysopoulos]

Hello Nick,

Thank you for getting back to me. I am wondering, considering the current planning (and without the project requiring a "cut" from the profits) what is the difference between the App Store and the JED? I mean, since the JED is planned to be rebuilt (as far as I've understood) you could do a few essential changes to converge JED and App Store:

• Add a "Subscribe" or "Buy" button in Commercial extensions
• Include an "App Store" component in the CMS which pulls and lists the JED contents, allowing one-click installation (free extensions) or redirection to the developer's purchase page (commercial extensions) <-- This is what WordPress does, with great success I may add
• Allow developers to update their JED listings with an API

In other words, JED is almost an app store, it just needs automation for developers and integration to the CMS. What do you think?

Cheers,

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Nick Savov]

+1

[Nick Savov]

You're welcome, Nicholas!

I was just sharing my personal opinion on it. The Working Group for the
AppStore-like feature would have to decide if they want a distributed
system, similar to what I've suggested, or an AppStore-like feature where
OSM handles all the money, etc. The latter would require OSM to be a lot
more hands-on in the process, get more lawyers involved, etc. Based on
past precedence, my guess is that the distribute method will be chosen
since there's less liability and less hassle for the project.

Yes, +1 on using what the JED Team comes up with JED 3.0 and working very
closely with them. They've been doing a great job working on the specs for
JED 3.0 and once they are ready, the AppStore working group can work with
them for an integrated solution. That being said, I think it's very
important that we not get in the way of JED Team finishing up JED 3.0 and
introducing scope creep for them. It's also important that we don't end up
with two competing "directories", but rather integrate the two. Whatever
they decide/implement, we'll go from there and see what we can offer to
the table. I think you're right on par with the suggestion that you had
and several other people have expressed the same interests.

Kind regards,
Nick

[Mike Hamanaka]

The past, current, and future well organized information available in the JED is a blessing for the community.

However, in my opinion an OSM sponsored separate fresh approach to an "app-store" which could be a fork of the JED would be a good idea and most practical.

I know that the archived 1.5 extension info was at one point made available for anyone who wanted to host a copy of that information to do anything they wanted with it...

Joomla itself is free software that I can have and sell, but the current information on the JED is not, it is available for general use, but I can't go and scrape it and start my own private directory fork from it.

An OSM sponsored appstore could in fact legally import the entire mosets db tables for use in any manner. Some efficiency could be gained in this manner.

Actually the JED is an information clearinghouse, and could offer it's best information to an appstore on an on-going basis since it is well-eatablished.

All of the above said, without consideration for other previously presented problematic issues which seem insurmountable without a fairly large undertaking, the identifiable areas of risk, better shouldered and sorted by competitive entrepreneurs either in part or in whole, rather than OSM, given the right resource assistance from OSM.

Mike Hamanaka
Website Production
Vertualize.com

[Paul Orwig]

More great feedback, thanks all!

Just to be clear, both CLT and JED have been involved in the initial discussions for the direction of this overall project goal, and they will continue to be as this continues to move forward from the current very high level concept.

Best,

paul

[brian teeman]

On Friday, 24 May 2013 18:37:33 UTC+1, Michael Hamanaka wrote:

I know that the archived 1.5 extension info was at one point made available for anyone who wanted to host a copy of that information to do anything they wanted with it...

That was a suggestion but it didn't happen for many reasons. 

[Bakual]

I would vote for this as well

 

Make the JED (or its data) available within Joomla with one-click installations and I would be happy.

 

The worst thing we could get is a complete different directory where we have to update JED and the App Store on each update.

email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send an email to
joomla-de...@googlegroups.com.
Visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google
Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send an email to
joomla-de...@googlegroups.com.
Visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups
"Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an

email to joomla-dev-general+unsub...@googlegroups.com.

To post to this group, send an email to
joomla-de...@googlegroups.com.
Visit this group at
http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-general+unsub...@googlegroups.com.

[Donald Gilbert]

I'm sure most of you have seen this, but Michael Babker and I worked on something similar to the "App Store" idea with our J!Lite poc. You are able to browse and install extensions from within the Joomla admin. See a demo of it in action here: http://www.youtube.com/watch?v=DDnYA2aQz5I

It's based off of the work done for the Languages installer and works fairly well.

Michael and I had a length discussion about it a few months back; you can see our chat logs here: https://github.com/JLite-POC/IRCLogs/blob/master/12-18-12_irclog.txt#L56

To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.

[Júlio Pontes]

Here its my concept of installer idea for "App Store".

http://www.youtube.com/watch?v=G9Ccuhg-0W8

code its on my github.

https://github.com/juliopontes/joomla-cms

The diff that I've add support for 3rd devs can create your own extension server list.

demo:

http://installerpatch.cloudaccess.net/administrator/index.php?autologin=1&passwd=installer&username=installer

[Thomas PAPIN]

The two "proof of concepts" from julio and michael look similar to me.

I like the idea of julio to be able to install your "own extension server list" like linux repository. you could have the JED officiel repository and some other repositories.

If the goal of the app store is also to gain some "profit" on commercial extension. Maybe another possible solution instead of the "commission" will be to charge a yearly fit to be able to post commercial extensions to the JED. 

Anyway, my suggestion will be to :

- start with "free extension", to split the problem.

- ask developpers to give there XML update URL in the JED form.

- generate a XML repository which will list all components that have a XML URL in the JED).

- update Joomla Installer to use this XML. (and allow to set other repositories)

This will be a first step, but a BIG BIG step (without a lot of dev needed)

2013/5/24 Júlio Pontes <julio...@gmail.com>

[Júlio Pontes]

in joomla already have a offical jed file but its empty.

http://update.joomla.org/jed/list.xml

[Donald Gilbert]

It may also be worth looking into Composer and Satis (modern PHP package management solutions) as they are already capable of installing Joomla extensions. 

—
Sent from Mailbox for iPhone

[Thomas PAPIN]

But this will be maybe more for 3.5 or 4.0 ? do you think it's possible before ?

for 3.2 the "adaptation of the update XML file" seems to be possible.

2013/5/25 Donald Gilbert <dilber...@gmail.com>

[Paul Orwig]

@Donald - The recent (3.0) language manager feature can install a Joomla extension (language packs) from the backend. Do you think there would be advantages to using Composer or Satis?

@Thomas - My thought is any app store solution would not happen until 3.5 at the earliest.

paul

[Donald Gilbert]

We can leverage the work already done, of course, and that would be recommended in my opinion. However, there would be advantages with using Composer / Satis where the system could handle dependency management between extensions. So, say there were a new CCK that depended on RAD, the creator would add which specific version of RAD he required, and composer would install it if a qualifying version wasn't already present. 

​That would be the main benefit I see with using composer, the built in dependency management, something our language solution doesn't currently offer.  

—
Sent from Mailbox for iPhone

[Paul Orwig]

Thanks Don, that helps!

[Michael Babker]

Our extension installer package as a whole completely lacks dependency management support at the moment.  There's already some work on the table to overhaul that package (progress can be found at https://github.com/joomla-projects/joomla-cms/tree/feature-JInstaller), we could look at hooking Composer support in as well with this update.

[Nicholas K. Dionysopoulos]

Doesn't composer require public repositories? What if I want to provide a commercial extension w/ dependencies to my other commercial extensions? Am I forced to provide everything for free to satisfy Composer's mode of operation?

Another issue. If a user's subscription expires he can still install and use my commercial, GPL licensed software as long as he has the installation package. With the Composer method he won't be able to do that (unless I am forced to provide everything for free).

Another problem. You suppose that all servers allow outbound connections to any IP. This is not the case. On quite a few servers you need to contact the host with a list of IPs and ports to open in their firewall. 

Another two problems. Can a user select which version to install with Composer? Can you have post installation packages with Composer?

Composer is great if you have SSH access and know what you're doing. I am not quite sure it's the best way to mass distribute extensions to non developers and often enough nearly tech illiterate people.

Nicholas K. Dionysopoulos

Lead developer and owner, Akeeba Ltd. 

[brian teeman]

On Saturday, 25 May 2013 07:30:01 UTC+1, Nicholas Dionysopoulos wrote:

Another issue. If a user's subscription expires he can still install and use my commercial, GPL licensed software as long as he has the installation package. With the Composer method he won't be able to do that (unless I am forced to provide everything for free).

Which would be a restriction on my gpl freedoms.  

 

[Herman Peeren]

Composer is for devs not for users and deployment or distributing components.

I also for a long time thought Composer/Packagist was the way to distribute software to users or deploy components. But it is not (or at least: not yet). I live in a world of devs and everybody uses Composer, I love it, it's really great, just take that DI-container from Symfony stick Doctrine to it etc. But it is all in the dev-world.

[Nikolaos K. Dionysopoulos]

In theory you could still keep a copy of the programme's source code and manually install it on your site. Nothing restricts you from doing that, therefore your GPL freedoms are not violated. It's not a question of legality, it's one of practicality. Even though what I describe is possible and can be carried out by an experienced developer, the bulk of Joomla! CMS users (which are the target group of the app store) are nowhere near capable of doing that.

Considering that this is the most frequently asked pre-sales question I receive and seeing how it could(?) be affected by the Composer idea I am asking people more experienced with Composer –like Don– to please address my question. Perhaps I am not understanding something correctly?

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Herman Peeren]

On Saturday, 25 May 2013 08:30:01 UTC+2, Nicholas Dionysopoulos wrote:

Can a user select which version to install with Composer?

 Yes, that is really easy: just define it in your composer.json file.
Look for instance here, for all versions of Doctrine: https://packagist.org/packages/doctrine/orm

Just copy the require-line in your composer.json and install. Soooooo easy. With PHPstorm you can just pick the packages from a list (and define which version you want). Not even a copy-past or a commandline necessary: it's all done in the background.

Really, a PHP-dev in this time would miss a lot if (s)he is not using Composer.

[Youjoomla.com]

App Store sounds ok but to be honest I would not give percentage to anyone. As Nik already advised we will be left with nearly nothing.

What I think is fair is one time charge of $20, - $50 max and only if we get exposure and if your "rules" change and we don't have to 

wait 60 days for someone to "decide" if they will publish it or not.

And you should consider opening template directory which we all ( template devs)  wanted to have on JED since Mambo time. 

Look on bestofjoomla.com , how many template providers do you see?

Each of them release min 1 template per month. We should be able to post those on JED as well. Not only extensions.

On Sat, May 25, 2013 at 9:20 AM, Herman Peeren <herman...@gmail.com> wrote:

Composer is for devs not for users and deployment or distributing components.

I also for a long time thought Composer/Packagist was the way to distribute software to users or deploy components. But it is not (or at least: not yet). I live in a world of devs and everybody uses Composer, I love it, it's really great, just take that DI-container from Symfony stick Doctrine to it etc. But it is all in the dev-world.

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-gene...@googlegroups.com.
To post to this group, send an email to joomla-de...@googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Best Regards
Dan Casky
Youjoomla Customer Service
+1727-388-6653
1670 Southgate Mill DR NW
Duluth ,GA
30096
-------------------------------
www.youjoomla.com
Professional Joomla Web Design Services

[Nikolaos K. Dionysopoulos]

Thanks, Herman! I forgot about it. I'm a Composer n00b. I started using the tool very recently, I'm not "there" yet with my understanding of it :)

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Herman Peeren]

On Saturday, 25 May 2013 09:55:41 UTC+2, Nicholas Dionysopoulos wrote:

Thanks, Herman! I forgot about it. I'm a Composer n00b. I started using the tool very recently, I'm not "there" yet with my understanding of it :)

Hope you'll plan some time to play around with it. Composer/Packagist is so much fun! The ultimate dev's wet dream: all those Lego-bricks so easily available. In 5 minutes you click your own framework together and can start building an application. Monolitic frameworks are from the past. If you visit some more general PHP-conferences, not just Joomla, you'll see it used in every presentation.

But, as I said, unfortunately this beautiful toy is not for deployment (yet) and so at the moment not relevant for an extension store. Or are there allready some applications for software distribution that use the same API as Composer but are made for distribution of software to users? Or are there plans to build something like that for a Joomla extension store? I mean: based on the same principles of a composer.json-file, but not using Composer itself; something that can also be used to install software from within a Joomla-installation on a shared host?

[Donald Gilbert]

Nicholas every problem you mention is a problem with any search and install interface for extensions, not just composer. Also, your assumptions about requiring public repos are incorrect. If you re-read what I posted, you'll see i mentioned Satis, which is a self hosted composer package server much like Packagist.com. 

On top of all that, composer is just a bunch of php files running a dependency management program. While there isn't CURRENTLY a GUI interface to do such management, there certainly could be. 

​So, to answer all your fears. No, extensions don't need to be public. No, extension dependencies don't need to be public. No, you don't need to have SSH to use composer. Yes, you can install specific versions. No, you cannot install conflicting versions.  

Also, I won't mention that WordPress has had search and install extensions for years with only positive effects on their market share and developer / end user happiness. Oops, I just did. [ obligatory emoticon :) ]

​ 

—
Sent from Mailbox for iPhone

[Donald Gilbert]

Of course it would be. And that would be the case with any and every extension installer that allowed you to install commercial packages, if that extension installer also did not allow you to download the zip as well. Sounds to me like we should just ban commercial extensions from the App Store so Brian's GPL Freedoms don't get stepped on. 

—
Sent from Mailbox for iPhone

--

[Donald Gilbert]

Herman, your IDE provides the GUI for composer. If we decided to look into composer for its dependency management benefits, we would obviously build the easy GUI for using it within Joomla. It's not just for devs. :) 

—
Sent from Mailbox for iPhone

--

[Donald Gilbert]

Herman your last paragraph there describes exactly what would have to be done to use composer in Joomla. And yes I mean use composer itself, not something else. We would use the libraries and code already available within composer itself, no need to reinvent the wheel (I detest that saying) we can put a nice GUI on it so even my 2 year old son could use it on his Bob-the-Builder laptop and not get lost, and there you go. Composer !== command line tool. That's just the most popular usage since a GUI hasn't been created fully yet, (if you don't count packagist.com)

—
Sent from Mailbox for iPhone

--

[Websiteconcepts]

takes some time to understand his way of saying things, but then you got to love Don ;-)

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

[Nikolaos K. Dionysopoulos]

Hello Don,

Thank you for addressing my questions. I now understand what Satis is (link added to help anyone else looking for it).

Other developers might wonder how it can be used for commercial extensions as it doesn't support any sort of authentication as-is. Apparently you need to use .htaccess/.htpasswd to limit access to the repository directory maintained by it. Adding thousand of password pairs is crazy, so you need to use mod_auth_mysql. Of course it takes a custom user plugin to sync user accounts with the Apache authentication database, using a semi-random username/password (different from the one used by the user on your site for security reasons). Then you need another content plugin to produce a specific repository URL for each client in the form of http://username:pass...@packages.example.com. I suppose that a Joomla! interface for Composer would only ask you for this URL, the package name and optionally the version you want to install.

I only have one more question (for Don and Herman): supposing that a user's server doesn't allow them to pull the information off my repository, I have to provide them a package. Would it be the same ZIP package as the one we're using today, or would we need a different format? I don't see Composer supporting installation from a package file. I'm a little confused as to how that would be implemented.

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Donald Gilbert]

Sorry all about coming across harsh. Thanks Ruud for the vote of confidence and reminding me I don't always sound to others as I sound to myself. 

​Nic, I'm not saying these are perfect solutions. And I'm not even saying they are valid solutions. What I am saying is that there are tools available that do some of the things I'd like to see the Joomla App Store do as well, and that it would be worth looking at those tools for guidance / an example. 

—
Sent from Mailbox for iPhone

[Nikolaos K. Dionysopoulos]

Hello Don,

No solution is perfect :) I just think that a Composer-like approach may be something interesting. If not anything else, it's an interesting thought exercise. My question on packages was honest. I couldn't find anything about package files in Composer's documentation. Does such a thing exist?

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Herman Peeren]

My opninion:
1. that major PHP CMSs will certainly go in a composer-like or composer-based direction for all dependency-handling, including deployment.
2. that it is not in the first place  the lack of GUIs that gives the possibility to let this happen, but the fact that many shared hosts don't let you use some necessary direct access. The last months for instance I saw some hosts putting allow_url_fopen to off. Not every Joomla-website can be automatically updated too.

I think that if some automatic installation is done, with or without Composer, you also always have the possibility to "manually" install a package. That stays the same. I only don't know if the dependencies on pieces of other packages will be handled too then.

So, I like Composer very much, I'm sure it will have a great future, but at the moment it still is a tool for devs.

[Amy Stephen]

+1 Statis - It's remarkable. Combined with other elements (JIssues customized as a JED?) it can be the element that manages distributed install/update nicely. It can process zips, work behind a secure environment, create distributions that are easier for users to manage, it's easily extendible. It's the different between letting a team obviously skilled and experienced in this area do your work for you, free of charge, or eating dogfood.

[Amy Stephen]

Reading these comments reminds me that this is a new environment most people. There are some misconceptions in these responses. Hopefully, these bullets and links will help.

Composer - http://getcomposer.org/

Primary purpose is facilitating installations and updates; it can source code from zip files, github, public or private repositories.

Secondary purpose is to manage dependencies, versions, and create full distributions.

The composer.json file provides the instructions for what software needs to be included and where to get it and what version(s) are acceptable. These files can be archived for version support. Alternatively, the project can use Composer to create a distribution, too, and store it in a zip on the github repository. Lots of options.

Important points: Composer installs software at the location the developer chooses. All questions about access to the code would continue to be managed by the developer. The project would not have to (nor would I want to see it) host the software. It's not necessary.  That's the beauty of this approach.

Good read on custom installers => http://getcomposer.org/doc/articles/custom-installers.md

Packagist

Packagist is nothing more than a central listing of code located in many places. It's akin to what JED is today. 

Satis - is like Packagist.

The project could use Satis to create a Joomla-specific Packagist -- i.e., a JED, to organize a list of extensions that can be installed. 

Using Satis, the project could replace much (not all) of what JED does. Developers can still keep their software in a number of places. They can distribute using zips or link directly to a repository. The repository can be behind a secure environment or out in the open. The options available today are extensive and certainly can meet the needs of the Joomla community.

Satis (Packagist) and Composer, combined, would mean everything JED does now, plus one important improvement. Users could install software centrally. Nothing else would have to change  about how developers store their software, or support their customers, or secure or open access to the software. It would merely add install and upgrade capabilities on top of what exists today.

Since the concern about possibly restricting GPL freedom was raised, I hope it's clear now that such is not the case. What this could do is give users more capabilities and retain everything they have today. Obviously, we don't want to restrict access to software, so it's a reasonable concern to raise, but the reality is how the software is shared now would continue to be the way that software is shared in this environment. There's just a layer on top that helps locate and install the software -- where it's at and how it's secured or not secured does not have to change.

[Websiteconcepts]

Thanks Amy for a nice summarizing kudos 

Ruud van Zuidam
M  DE :  +4915730448257 oder  NL : +31637170938

[Herman Peeren]

Anyone any clue how to use Composer with a Joomla-installation on a shared host with only FTP-access, no SSH/CLI? I've probably missed that part.

What I normally see is:

• use Composer on your local development server and then upload the installed files to a production server / shared host.
  
• or use a VPS. That is very affordable nowadays, but not a requirement for Joomla (nor the most common case).

I really hope I see this wrong, for I like Composer very much and it will for sure once used as an installer. For now it is primarily a dependency manager, not an installer for users. Does anyone have any example to execute the composer.phar on a common shared host?

[Amy Stephen]

Herman - think of this as workflow and tools. Don't make assumptions that users would be using these tools, with the CMS, I don't see users even knowing about Composer. Rather, I see the project implementing automation that uses Composer  as a tool to create a zip file that would then be automatically moved to Github (or somewhere else) to be available for download. That's where your every day user would be involved. To them, it can look very much the same.

Watch Michael and Don's activity on github. They work with these tools, CI environments, and so on, if you follow them on github you can start picking up some of these tricks and see how they are building these automations with JIssues and the Framework.

--

[Nicholas Dionysopoulos]

Amy,

I believe you need to go back about a dozen posts in this conversation. Nobody was talking about using Composer to create ZIP files. Also what you call an assumption? It was actually the topic of the conversation. Plus, Herman wasn't implying what you understood. Please refer to the previous posts for context.

Nicholas K. Dionysopoulos

Lead Developer, AkeebaBackup.com

Web: https://www.akeebabackup.com

Blog: http://www.dionysopoulos.me/blog

Sent from my iPad. Please excuse my brevity.

[Amy Stephen]

On Sat, May 25, 2013 at 2:16 PM, Herman Peeren <herman...@gmail.com> wrote:

I really hope I see this wrong, for I like Composer very much and it will for sure once used as an installer. For now it is primarily a dependency manager, not an installer for users.

Hi Nic. I was responding to this comment from Herman. He voiced these concerns earlier, too. I agree with him that users will not use these tools. What I am pointing out is that Composer can be used to create those same type of zip files that Joomla offers today. Just part of the workflow. Hope that clears up any misunderstanding.

In case anyone wants links to follow Michael and Don on github.

https://github.com/mbabker

https://github.com/dongilbert

You might also be interested in seeing the installers already available. I was surprised to see Joomla extensions in that list when I stumbled on it a couple of weeks ago. https://github.com/composer/installers/tree/master/src/Composer/Installers

[Herman Peeren]

Thank you, Amy for restating what I also tried to say: that Composer is a great tool for devs. We agree on that. I'm familiar with the tool (and a "fan").

I thought the issue was: could Composer be used as an installer for users of the Extension Store (the JES?)? Can it be used to install extensions in a Joomla-installation (on some shared host, as is the common use).

[Amy Stephen]

Right, and that's what I am trying to say, that the interface we use as developers with the composer.json file. -- that will not be the interface for users, but Composer can be used for Users with a different Interface.

In the case of a distribution, it can be a zip. So, your questions about FTP or shared hosting are the same today as it will be then. I do not see users using composer.json. I see them using zip files, like now. Only difference is Composer can create those files.

In the case of an extension, it could be the be a link on an Extension name in an internal Admin list that will prompt an install that will invoke Composer from a command prompt and perform an install or upgrade.

Composer.json is a great tool for devs, not Users. But, Composer itself - with the right interfaces - is a great tool for everyone. It's just a matter of thinking thru the work flow and building the integration.

On Sat, May 25, 2013 at 3:18 PM, Herman Peeren <herman...@gmail.com> wrote:

Thank you, Amy for restating what I also tried to say: that Composer is a great tool for devs. We agree on that. I'm familiar with the tool (and a "fan").

I thought the issue was: could Composer be used as an installer for users of the Extension Store (the JES?)? Can it be used to install extensions in a Joomla-installation (on some shared host, as is the common use).

--

[Herman Peeren]

On Saturday, 25 May 2013 22:14:40 UTC+2, Amy Stephen wrote:

You might also be interested in seeing the installers already available. I was surprised to see Joomla extensions in that list when I stumbled on it a couple of weeks ago. https://github.com/composer/installers/tree/master/src/Composer/Installers

OK, this might be the misunderstanding: you refer to a Composer installer, which is, in spite of the same name, something different from the installer we were talking about for an Extension Store, I think. 

Donald started about Composer, saying: "It may also be worth looking into Composer and Satis (modern PHP package management solutions) as they are already capable of installing Joomla extensions". I got the impression that he meant: to use it in the installer, to be used in your Joomla installation by a user. I think in the future it will go more or less in that direction, but not yet. I got the impression Donald sees possibilities to use Composer in such an installation for end-users NOW, or in the very near future: to be implemented in our JES. Dear Don: am I right or wrong with that assumption? What is your vision/opinion on that?

[Amy Stephen]

I agree with Don's comments completely. But, no, that's not what he meant. That's really not a complete functioning install. It's just a start, something we can use to build the solution. I believe he is speaking about this as I did in my last post, that Composer can be a component part of a bigger solution for the Extension Store/JED solution.

Definitely want a point and click WordPress-like interface on there with searching, and so forth, but with that in place, it can issue CLI commands to instruct Composer  to do the install. Satis can be used like JED to display the listings. Developers can continue to store their extensions - secured from view - or open to the public - just like today.

Earlier, Nic made a good point about the hosts that are strict about remote installs. We'll still need a manual process, no matter what is used to fetch the remote code, because a host can shut that down.

--

[Herman Peeren]

On Saturday, 25 May 2013 22:29:06 UTC+2, Amy Stephen wrote:

In the case of an extension, it could be the be a link on an Extension name in an internal Admin list that will prompt an install that will invoke Composer from a command prompt and perform an install or upgrade.

So, if I understand you well: Composer is running on the server with the Joomla installation (let's assume the common case: on shared hosting). And it is invoked by a link. Which of course must be very well protected for this would be a great tool for hackers to install anything too. But let's assume that will be solved.

Interesting. I also think we will go in that direction, some time, but I have not seen something like that yet and I think we cannot use that now. But this is just what I hope for to be wrong. I would like to see an example of such a use. Has anyone done that yet?

 

[Amy Stephen]

Yup, that's more how users would engage with the environment. And, it's doable now. Many shops use Satis today to support their customer communities. Don might be aware of Laravel commercial devs doing the same.

No matter what, designing this and building it for Joomla will take time. Just thinking through the workflow is going to be a lot of work. The software is likely the easiest part. But Don is right that there is a good deal of software written and available for us to plug into the right places when the time comes. And for those who love to code, plenty of that will still be needed to build an intuitive interface.

Also - if someone has command line access to your website, you're in big trouble anyway. ;-) This really is not any more dangerous than the upgrades in place, etc.

I can look around for examples, Herman. But, yea, that's more how I see it and how I think Don was describing it, too. (Could be wrong, always dangerous "speaking for" someone else.)

 

--

[Donald Gilbert]

Herman, I was not saying Composer is ready for Joomla to use now. I'm saying it, coupled with a new Satis powered JED could do wonders for the way users search for and install extensions. This would take time to flesh out and produce, but it's worth looking into as a place to start building our App Store, since that doesn't exist and is something we need to build. 

​As far as everyone's concerns with remote installation being possible in most Joomla environments, that is NOT A PROBLEM SPECIFIC WITH COMPOSER. I capitalized for emphasis, not to yell. It's not a problem specific to composer, it's an issue ANY remote extension installer would have to work around. I should also reiterate, our competitor WordPress has had this ability for years, with no known issues. IIRC their market share grows faster than ours? So however we solve this, lets do it at least as good as them. I don't care if its composer, I was merely offering a possible starting place. And if Joomla can do extension installation BETTER than WP (via dependency management as well) then I think we'll finally be able to put on our big boy pants again and be proud to be Joomla. 

—
Sent from Mailbox for iPhone

--

[Amy Stephen]

On Sat, May 25, 2013 at 3:49 PM, Herman Peeren <herman...@gmail.com> wrote:

On Saturday, 25 May 2013 22:29:06 UTC+2, Amy Stephen wrote:

Interesting. I also think we will go in that direction, some time, but I have not seen something like that yet and I think we cannot use that now. But this is just what I hope for to be wrong. I would like to see an example of such a use. Has anyone done that yet?

Herman - here are three quick examples I found on Google that might be worth exploring.

• Alessandro (some might know him/remember him from Joomla). He has written an installer that works with Symfony's CLI - 
• Drupal is using it in much the same fashion as we were discussing - with a Web page and the command line, they are integrating it in with Drush
  
• Here's an example from CakePHP
  

Also a link to Composer's CLI API

Looking back, I can see how my comments might have been misleading. Sorry about the confusion, Nic and Herman. I think (hope!) it's cleared up now, but I'll try to respond more carefully in the future.

[Paul Orwig]

Hi all,

The blog announcing the app store study group has been published:
http://community.joomla.org/blogs/leadership/1749-app-store-study-group-forming.html

The next step is to form a study group to research the main issues and give recommendations on the best way forward. For those who are interested in joining the study group, the blog includes a link to a short Google form.

Thanks to everyone in this thread, in other threads, in conference sessions and private discussions for all of the really good ideas and brainstorming on this idea. I am really excited to see this move forward, and I am looking forward to seeing what we will create and share - together.

Best regards,

paul

--

[Nikolaos K. Dionysopoulos]

Thank you, Paul!

Nicholas K. Dionysopoulos

Email: niko...@gmail.com

Blog: www.dionysopoulos.me/blog

[Nick Savov]

+1

> Thank you, Paul!
>
> Nicholas K. Dionysopoulos
> Email: niko...@gmail.com
> Blog: www.dionysopoulos.me/blog
>

> On 27 ��� 2013, at 17:46 , Paul Orwig <paul....@opensourcematters.org>

[Paul Orwig]

Hi all,

Good progress has been made on the Joomla app store (unofficial name), but more coding help is needed if this new feature will potentially be included in 3.2 beta (current estimate is that's about a month away). If this feature doesn't get included in 3.2, then it will likely have to wait until Joomla 4.0. 

A shared document has been created that defines the architecture and UX design for this:
https://docs.google.com/document/d/1GykMS7YRVg9igSWO7lpPxJp36BXmz1syB1m3rw-qAZA/edit?usp=sharing

If you are interested in helping with any of the coding tasks that are mentioned at the end of that document, please follow up with David Hurley (david....@joomla.org) as soon as possible.

Thanks,

paul

On Wed, May 29, 2013 at 11:43 PM, Nick Savov <ni...@iowawebcompany.com> wrote:

+1

> Thank you, Paul!
>
> Nicholas K. Dionysopoulos
> Email: niko...@gmail.com
> Blog: www.dionysopoulos.me/blog
>

> On 27 جلْ 2013, at 17:46 , Paul Orwig <paul....@opensourcematters.org>