4 ms·

where is the github repo ... the github organization ? there is no link to any source code anywhere. It may be an oversight, or a hesitation to open it too ear

where is the github repo ... the github organization ? there is no link to any source code anywhere. It may be an oversight, or a hesitation to open it too early. But here at HN, it gives me an uncomfortable feeling for a cabal that may bait-and-switch. For example, I have zero idea of whether you are going to use a MIT license or Apache or whatever. Why is this so secretive ? We have been looking to throw our weight behind an open community platform that can compete with magento. Im hoping you guys can be that... but you need to be open right from day zero. P.S. oh and I second the ORM comment. Like seriously. It will be a horrible mistake not to use one.

aritali 10y ago
I can speak to the GitHub repo and source. Basically a lot of the companies that are forking are agencies that are affiliated with PrestaShop. We are bound under certain contracts (not ones that deal with the OSL though). We basically decided this move this week. The reason the GH repo is not public yet is because we are changing the licensing (the copyright attribution not the type) and the branding. Also we are going over the code and commenting what is PrestaShop's and ours. On a basic level we are trying to do everything right with the code to cover our asses and not get sued. As for the license we are not experts in licensing, we are developers. It seems easiest for us to keep the same license that is on the code than to try to transfer it to another system. It is going to stay under the OSL 3.0. That being said, that is why we have the mailing list sign up. We are shooting to have everything cleaned by early in the week where we can release the public repo and a road map of what needs to be worked on. This is going to be a totally open source project, we are just trying to do it in a way that will not end up in us getting sued for some minor violation of the license. As for a community platform, that is what I am going for. I own an agency that manages around 800 PrestaShop websites. I see my clients leaving. I see them leaving for stupid reasons (not on their part, stupid reason on PrestaShop's part). I am trying to stop the bloodletting in my company and give my clients what I hear them asking for. Transparency is what we are going for. I want users to suggest features. I look at other platforms often and say things like 'damn that would make a nice core feature'. Its part of the reason we are breaking off. There is nothing more demoralizing than spending a day or two working on a feature for an open source platform then they reject it. Not only do they reject it, the company (PrestaShop) takes the idea and sells it as a paid module. This happened to one of our developers. tldr: We are going to be totally open source under the same OSL 3.0 license we just need to properly deal with and attribute the code before we release it to try to prevent a lawsuit.
themaveness 10y ago
We have the GH organization created. Its all private for the moment. Basically we have never forked a software like this before. We are going over the license and trying to make sure all our i's are dotted and our t's are crossed so we do not end up in a lawsuit. The project will totally be open source, it will be under the same license that the code is currently under OSL 3.0. We aren't trying to bait and switch I promise. This is something we have been talking about for a couple of months, but we decided on this week. So when we open the repo to the public to help with we just want to be in a position we can defend if it happens to go to court. Nothing kills a good idea faster than an opening day lawsuit. We would love it if you guys helped. We need it.
- zebra9978 10y ago
  thank you for clarifying that. However, I think after reading the comments below that the scope of the project is to maintain backward compatibility with the agencies/authors of plugins in the Prestashop ecosystem. What we were looking for is something that was trying to do new in the webshop ecosystem. Even I misjudged your "lack of MVC" comment below. My perception was that you were bringing together a lot of people from the Prestashop community and building something new with modern day best practices. Using an ORM is the smallest of them. MVC is another. asset pipeline could have been a third. But if you attempt any of this.. you will risk breaking backwards compatibility with any number of plugins out there. Which is why I'm doubtful you will try to do anything new. The way I see it is that you will maintain a bugfixed release of Prestashop 1.6 with incremental changes to support the plugin ecosystem out there. Personally, I think you are aiming too low. You want to make something better than Prestashop 1.7 which is why your holy grail is to maintain backward compatibility and fix some plugins (like the Paypal one you talk about). But from what I have seen, your real competition is the Shopify of the world. Even Magento 2. Not sure if you have seen the docs, but Magento 2 has started adopting best practices out there: 1. composer for dependency management - http://devdocs.magento.com/guides/v2.0/install-gde/prereq/integrator_install.html#instgde-overview-composer http://devdocs.magento.com/guides/v2.0/install-gde/prereq/in... 2. database migrations - http://devdocs.magento.com/guides/v2.0/install-gde/install/cli/install-cli-subcommands-db.html http://devdocs.magento.com/guides/v2.0/install-gde/install/c...

aritali 10y ago

I can speak to the GitHub repo and source. Basically a lot of the companies that are forking are agencies that are affiliated with PrestaShop. We are bound under certain contracts (not ones that deal with the OSL though). We basically decided this move this week. The reason the GH repo is not public yet is because we are changing the licensing (the copyright attribution not the type) and the branding. Also we are going over the code and commenting what is PrestaShop's and ours. On a basic level we are trying to do everything right with the code to cover our asses and not get sued. As for the license we are not experts in licensing, we are developers. It seems easiest for us to keep the same license that is on the code than to try to transfer it to another system. It is going to stay under the OSL 3.0. That being said, that is why we have the mailing list sign up. We are shooting to have everything cleaned by early in the week where we can release the public repo and a road map of what needs to be worked on. This is going to be a totally open source project, we are just trying to do it in a way that will not end up in us getting sued for some minor violation of the license. As for a community platform, that is what I am going for. I own an agency that manages around 800 PrestaShop websites. I see my clients leaving. I see them leaving for stupid reasons (not on their part, stupid reason on PrestaShop's part). I am trying to stop the bloodletting in my company and give my clients what I hear them asking for. Transparency is what we are going for. I want users to suggest features. I look at other platforms often and say things like 'damn that would make a nice core feature'. Its part of the reason we are breaking off. There is nothing more demoralizing than spending a day or two working on a feature for an open source platform then they reject it. Not only do they reject it, the company (PrestaShop) takes the idea and sells it as a paid module. This happened to one of our developers. tldr: We are going to be totally open source under the same OSL 3.0 license we just need to properly deal with and attribute the code before we release it to try to prevent a lawsuit.

themaveness 10y ago

We have the GH organization created. Its all private for the moment. Basically we have never forked a software like this before. We are going over the license and trying to make sure all our i's are dotted and our t's are crossed so we do not end up in a lawsuit. The project will totally be open source, it will be under the same license that the code is currently under OSL 3.0. We aren't trying to bait and switch I promise. This is something we have been talking about for a couple of months, but we decided on this week. So when we open the repo to the public to help with we just want to be in a position we can defend if it happens to go to court. Nothing kills a good idea faster than an opening day lawsuit. We would love it if you guys helped. We need it.

zebra9978 10y ago
thank you for clarifying that. However, I think after reading the comments below that the scope of the project is to maintain backward compatibility with the agencies/authors of plugins in the Prestashop ecosystem. What we were looking for is something that was trying to do new in the webshop ecosystem. Even I misjudged your "lack of MVC" comment below. My perception was that you were bringing together a lot of people from the Prestashop community and building something new with modern day best practices. Using an ORM is the smallest of them. MVC is another. asset pipeline could have been a third. But if you attempt any of this.. you will risk breaking backwards compatibility with any number of plugins out there. Which is why I'm doubtful you will try to do anything new. The way I see it is that you will maintain a bugfixed release of Prestashop 1.6 with incremental changes to support the plugin ecosystem out there. Personally, I think you are aiming too low. You want to make something better than Prestashop 1.7 which is why your holy grail is to maintain backward compatibility and fix some plugins (like the Paypal one you talk about). But from what I have seen, your real competition is the Shopify of the world. Even Magento 2. Not sure if you have seen the docs, but Magento 2 has started adopting best practices out there: 1. composer for dependency management - http://devdocs.magento.com/guides/v2.0/install-gde/prereq/integrator_install.html#instgde-overview-composer http://devdocs.magento.com/guides/v2.0/install-gde/prereq/in... 2. database migrations - http://devdocs.magento.com/guides/v2.0/install-gde/install/cli/install-cli-subcommands-db.html http://devdocs.magento.com/guides/v2.0/install-gde/install/c...