ZenMagick on github
Just a heads up that I finally moved the sources to github. That means sourceforge is only used for tracking things and downloads.
I guess in the long run we’ll have to find some other solution, but for now this will have to do.
The next step will be to split off all plugins as separate repositories, so it is easier to get other people involved in writing/committing code.
Of course it is essential to get other devs involved in the plugins.
IMHO it is also essential that these plugins be submitted to QA before publication.
One of the reasons OScommerce and Zen Cart have so many bad mods, is that they don’t do QA.
Prestashop is smart enough to certify all plugins they publish (I think, don’t know much about Presta).
Comment by Carlos Kosloff — February 18, 2010 @ 6:14 pm
I guess we could/should have some basic testing before adding plugins to our site. That won’t stop people publish/sell their own plugins elsewhere, though.
But I agree that any content offered on ZenMagick sites needs to be approved in some form
Comment by DerManoMann — February 18, 2010 @ 9:51 pm
I must say I strongly disagree with the requirement for approval before modules can be put on the site. That is the start of the slippery slope toward the sort of control freakry that plagues ZC.
I h=am sure they started their module vetting program with very good intentions but it is simply a dog’s breakfast right now and this project with fall into the same innovation stifling trap if it goes down that path. People must be free to offer contributions without some big brother interfering.
I recognise that some form of vetting is required but I would suggest you take a leaf out of the gallery2 project.
They have layers of add ons … Official and Community. Every G2 release is tested against the official contribs and these are updated to work with the release. This required a addon version compatibility code check when the program is loaded so that the addon is disabled if the addon code number for the program is higher than that in an addon.
So in effect, the G2 team guarantees these addons and similarly, if you do decide to vet addons, then you must guarantee them and basically support them.
The community addons are the second layer. These are just stuff developed by users. They may work or may not work. That is up to you the user to decide yourself.
The good thing is that many of the official addons started life as community addons before being brought into the project by the devs. The community keeps on actively developing stuff, they get help from the devs and experienced members and it works very well.
Both official and community addons are hosted by the project and can be pulled and installed directly from the program. As you need SVN knowledge to add to the community repo, it tends to be experienced people that add to this.
There is a third layer of which is basically second type of community addon by people like me who can’t be bothered to upload to svn. Stuff in forums posts, hosted on third party sites and the like.
Anyway, I would seriously rethink the vetting thing as the innovation killing nature of how they tend to go. What will happen when you start getting several submissions a day? Will you hire someone to do the vetting then or just let things slide and keep the submissions in limbo as happens with ZC? Will you, when the authors posts in the forum to ask what has happened to their submission, go in a release them thereby making a mockery of the reassurance that people have that you check stuff.
I say let people develop and offer their stuff freely. Adults don’t need any nannies. We can take the good with the bad.
Comment by Dave — February 19, 2010 @ 8:11 pm
It’s a tricky business. I don’t think anyone would want to stop people offering plugins just they are out of line with what we’d prefer them to be.
For me, this is more a discussion about liability. If I offer a download I do have some sort of responsibility. Look at the recent incident with a Firefox add-on. It contained a virus (or trojan, doesn’t really matter here). I really do not want to be in a similar position one day.
Sticking with Firefox add-ons: obviously we do not really have the resources to validate every submission. Right now there isn’t really any danger of having too many plugins anyway:)
But you are right, one has to plan ahead.
Testing for compatibility is obviously the second thing. Again, each developer should be able to get that right. On the other hand there will always be cases of side effects in combination with other plugins and there isn’t a lot that can be done about that.
I will have a look at g2. I’ll try to post again once I know a bit more.
Comment by DerManoMann — February 20, 2010 @ 10:14 am
Here is another example of a project offering layers of addons: http://wiki.nginx.org/NginxModules.
There are the core, standard, optional and third party modules there.
They can be grouped into official (core, standard and optional) and third party. I have just activated it on my site and know that the standard modules have been tested and vetted by the developers. Third party ones however, while available on the site, I can only install at my own risk. This is fine. I understand this and can work with this.
Some of the official modules started life as third party modules and this sort of thing helps develop projects.
The last thing I need is for the developers to say they wouldn’t put those third party modules up until they pass through them first.
The reality is that third party developers will always be on the bleeding edge and pushing boundaries. This should not be curtailed in any way.
The core and standard
Comment by Dayo — February 20, 2010 @ 8:15 pm
Control freakery…harsh words to describe the QA expression I used.
This simply means that add-ons offered as part of ZM have to be malware-free and not disruptive or conflicting, also with clear uninstallation instructions.
In other words, moderated.
I have seen add-ons offered in Zen Cart’s download site that caused a support nightmare and were described as the latest version.
ZM cannot take responsibility for a free-for-all upload party.
This is not control freakery, just common sense.
The idea of staggered layers is not bad and not incompatible with what I suggested.
Third-party add-ons will be the responsibility of the developers and the users who chose them.
Who can stop people offering third-party contributions?
Comment by Carlos Kosloff — February 22, 2010 @ 2:43 am
It is indeed harsh to call what you suggested control freakry and the post does not called it so. It simply says that such efforts, while started with good intention, are usually the start of the slippery slope TOWARDS control freakry.
Let there be a free upload system. Will there be bad mods? Yes but so what?
The project site should be a central point of reference for both official and community addons.
A third party addon downloaded even from the project site is not the project’s responsibility. It is simply a courtesy service.
Introducing a program that makes these unavailable or not easy to find is in no way in the interest of users and in any project that gains popularity, a bad idea.
As said above, we users can take the bad with the good as we are adults. Our old nannies can now kindly retire.
Comment by Dayo — February 25, 2010 @ 5:16 am
I guess a two
classlevel system would be ok, looking at the resources available. Plugins maintained by core developers would be flagged as ‘approved’ (is there a better word?) and all other wouldjustbe contributions with no guarantee whatsoever.We could also offer virtual listings where there is just a description and a link to an external site. This might be useful for commercial plugins to advertise (and could generated some money). It’s actually something I would like as developer/web shop.
I’ve done something similar by convincing the DPS people to add a link somewhere on theirs site pointing to my zencart DSP payment module. It just makes sense and allows to keep code in a single place.
Comment by DerManoMann — February 26, 2010 @ 12:18 am