We do have to take in mind, that Evan is trying to solution integration with packagist and composer. I am not familiar with packagist but composer could solve vendor dependancy. Not inter plugin  dependancy !

If packagist is really solving the zipping and redistribution might be true, let's see. I really do not mind zipping and publishing once I think that a new release is suitable or needed. I like github for my little changes or bug fixes and once I think it is time to release it, I will do the effort of making a zip and fill in some details about the change.

Simple suggestions: remove the need to upload if a code repo is given; prominent link to repo issues above comment form (and kindly ask users not to post issues); maybe rename comments to something like "Testimonials".

I definitely like the idea of auto-creating plugin objects for Elgg Packagist results. Good longer term goal.

We could also alter our plugin system to walk users through installing more complex plugins. Seems a lot easier than teaching community.elgg to do this work.

I mean, I tried but everything now makes me think this community was, is and will be dev-oriented only which is not necessarily bad of course, it is simply not for me.

There are so many other things that comes to my mind but never like today I feel they would be not well accepted.

I don't think it is dev-oriented. We help each other out. It is very open and even the core developers discuss about elgg changes in the community.

but I wonder if there's another way to give that confidence without the core team "backing" them?

I think hosting the plugins in the elgg community gives confidence to new users. I think this is more than enough.

I have some plugins that are not released here because they are too experimental and for very specific tasks. Besides, building a useful plugin takes time. The community is alive, we have several developers and a wide variety of plugins. Someone just released a plugin that integrates embed.ly, which solves the problem of embedding a link in The Wire or other places. The way I see it, you don't see plugins released every day because what we need for building a private network is already available in the plugin repository. Facebook login? Three plugins for that. Google Tools integration? There are plugins for that.

Just my 2 cents...

I did not read the whole discussion, but i see no need to drop the functionality of having a code repo here at community.elgg.org. Maybe the plugin that provides this plugin repo is flawed, but that could be fixed. As a plugin developer i need a centralized platform to provide plugins to my end users. This community is that platform. There is no alternative.

If you read correctly i said end-users. That means non-devs. If you are into code you can look up our plugins @ github.com/coldtrick, but that is not the place i would like to communicate with non-devs, as i do not want to use github as a platform to communicatie with end-users. I would like to see that seperated.

There is one thing that could power the plugin repo here at community.elgg.org and that is the ability to update my plugins through webservices. For example github has webservices to push when there is an activity in the plugin repo. Elgg could then check if there is a new release available and update the plugin database accordingly. That should however not be a full replacement, as not everyone will use github. Scraping packagist for updates is even less likely to be widely used.

The deciding factor for me was not the implementation of the community plugin database, and not the extra time that goes into packaging releases. Rather, a misconception that anything you find in this community is production ready, and that there is support for it. Most my work is quite experimental in nature, and even though most of it is plug-n-play, I do not want to create an impression that my plugins are an end-user product. Looking through my older code, I have realized how bad some of the code decisions were, yet instead of bug reports and suggestions for code improvements, I were receiving countless feature requests. The decision to keep things on Github, is to promote a better understanding of what people get - not a product, but open-sourced code. It is important to do a code review, testing and analysis, before you drop anything into your plugins folder, and I want to discourage people from blindly using my code, and then complaining that it doesn't work. Additionally, with a much faster Elgg release cycle, I can't physically keep up with all the things that need/can be done to improve things and make things work. I also can't always ensure backward compatibility (thought I am getting better at it), and I don't want to be stuck thinking of all the people that have used my plugins without considering the risks. The only end-users I should be concerned about are my clients, and the decisions I make about my code should be influenced by the future of their websites.

TLDR; I want to focus on my code, and not the end-user with a high appetite and nothing to contribute.

"the end-user with a high appetite and nothing to contribute"

imho, the use itself is the greatest contribution. The end-users who use your plugins on their web sites or spend time testing them, surely in my eyes, are contributors.

End-users high appetite is also concerned with code and code only - be it php or js css whatever. End-users probably want the code to do something this or something that. And it is the code only. Good programmer's do listen to that and on inner side of their soul they know how to filter out the noise. I think so but I may be wrong.

Feature request or enhancement is one very important part of git-hub also. But of course everyone has their choice and most of us do respect that.

yet instead of bug reports and suggestions for code improvements, I were receiving countless feature requests

Hypewall alone has 38 closed and 15 open issues as of now. Who made these ? I wonder if they are all your paid clients. I am sorry to say this, for one or two bad comments it is unfair to generalize. If you found some bad comments you could have used the system to "report" against the comment or commentator. If a person made too many bad comments it would have made a case for banning and thus you would have contributed to the community too.

@kanha, I agree. When things come in moderation, it's a great model and it works. I enjoyed working with the end-user for many years, and yes I have learnt things while at it. But lately, it has become a burden, and I am trying to eliminate it before I am completely burnt out. The decision was pragmatic, and in interest of noone but myself. I am sorry it has evoked such a debate. Yet I do not regret it - those with enough commitment will find their way to work with me on my plugins, but it will be without all the community pressure. 

Well, now consider this. I have built hypeWall for fun as a proof of concept. Why in the world do you expect me to even bother maintaining it? I could have built a custom solution for a client that does exactly that, instead I have released my code so others can make use of it. I didn't sign up to spending days fixing those bugs, or explaining to you why I have made a decision I made. Your attitude is exactly the point I am trying to make, and it's the kind of attitude I want to avoid in my daily work. The code is there, the code is open source, use it or leave it.