| 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/in... 2. database migrations - http://devdocs.magento.com/guides/v2.0/install-gde/install/c... |
We are going to end up rewriting things with better practices. This is something that HAS to happen. Its not the first thing we are going to do though. We need to build a userbase in the cheapest, quickest, easiest way possible. Not having to scrap everything, getting a more stable shop with new features is attractive to people.
I am purely looking at this from a business sense. Yes, we can take the code, we can convert it over 6 months to be something totally different, more robust, better designed, just bad ass code. In that time we can miss the window and not have as many shops migrate over to our platform. Thats not a good strategy in my mind. I see great ideas all the time on GH that have been abandoned because they are not profitable. We are trying to cut a middle line deal here in the beginning. We want to make a profit to pay for expenses and we want to give merchants what they want.
Once you have users in a platform it is easier to get them into a big upgrade than to try to get users from scratch, or get the to migrate. I realize (I think) you are looking at this from a purely code / application development stand point. Look at it from a business stand point. Merchants generally look at two things when evaluating a platform. Is my payment gateway accepted and are my shipping options accepted. If we break these things out the gate we will either be stuck writing all of these modules, or we will just lose those customers. On the other hand if we get them to migrate and have a grand plan later, the agencies and companies that keep up these modules will rewrite them. I am trying to mix logical business with logical development to come up with a successful plan.