Show HN: Thirty Bees – A PrestaShop 1.6 fork
thirtybees.com
thirtybees.com
… admittedly, I wouldn’t have even found the navigation if I hadn’t pressed Space.
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.
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.
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.
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.
I would even go to the extent of questioning any success you think you will have with the bugfix approach.
Prestashop inc has 9 million USD of funding. Your reason of existence will vanish the day that Prestashop fixes the few bugs that you have. What do you think will happen then ? Will you yourself continue on this fork... or will you say "oh well, the Paypal module works on prestashop 1.7 again"
If you are doing this, then do this for the reason you want to do it subconsciously - all the MVC stuff you are dreaming about.
>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.
There is zero incentive to stay. The advantages of your "new" platform are so minimal that people will instead make and buy new plugins for 1.7 . In fact sorry for being blunt, but the existence of your fork is just as long as it takes for all agencies to port their code to Prestashop 1.7.
If your users migrate, they will force you to never break compatibility. So you will basically become Prestashop 1.8 . There is no possibility of a grand plan later.
As someone that works in depth with PrestaShop, very in depth, I don't think they can do it. I talk to the founder regularly, I actually emailed him and let him know we were forking. I believe in that kind of courtesy still.
Let me ask you a simple question that might change your mind about things. How many developers do you think work on PrestaShop? Currently the company has about 120 employees. 4. There are 4 core developers. Out of 120 employees 4 developers. I know all of them. I respect them. I don't agree with them sometimes, but jesus I know they are regular guys in a shitty position.
I think the bug fixing approach will work. Maybe it won't. That is what I am betting on. Like I mentioned before, I am just one person in a machine being driven by other people. Sign up to our mailing list. When we release the code as OS we are going to have a gitter, we can all get in it and air our opinions and hash out a way forward. I am expressing my ideas not necessarily the ideas of the project. I will argue my case and if I lose I am going to do what I can to help the idea that wins. To me this is what being a community is about. We are working with a product that is under a totalitarian regime I feel. I am not leading people out of one into another. I am the first to say I don't have the best ideas. We want more collaboration. We want people from outside the Prestashop ecosphere to come in and give ideas. In the end these are things that will help us.
could you atleast put up the gitter and allow us to sign up there. mailing list feels very "commercial"
I have subscribed many mailing lists during my life and there is no single one that I could define in any way as "commercial".
On the other side, Gitter is a commercial platform that depends on one of two other commercial platforms (Twitter or Github).
I wonder if I should revide my opinion on the usage of Gitter for free software projects...
slack or gitter is atleast a two way street.
Did you look at http://sylius.org/ ?
Hopefully this will get off the ground, I signed up.
I hope they can turn this into a stable and powerful platform that I can recommend as a self-hosted solution over Magento (too bloated) and WooCommerce (easy to use, but tied to Wordpress and missing some important features).
Once we get things stabilized we are going to figure out the best way to rewrite things. That is why we are trying to be very community focused. We need to see the pain points of merchants, what they want, what would make them succeed.
We are scrubbing the whole platform for legacy code and updating what we can while maintaining compatibility with the current modules and themes. Then we are really going to break this down and develop something more awesome than awesome.
i think the golden usecase would be running thirtybees on heroku (postgresql, composer, php 7)
EDIT: there was a dead comment about how postgresql is not good. what im asking is different - im requesting for an ORM like Doctrine or Propel. This will let the end user choose the database that they want to use. But you have to take this stand pretty early in a project's life cycle or you will not be able to do it later. Exactly the issue with WordPress.
Some of the security issues in wordpress - unescaped queries, SQL injection and everything - which plagued it for decades could have been avoided by using a well tested ORM.
I would urge you to make this one of the highest priorities in your code cleanup. It is not going to take you a lot of effort, but the long term advantages are too many to enumerate here.
For example, for your own development sake - I dont know how you plan to manage schema changes. If you use Propel, you will use "database migrations" - something that every framework from Rails to Django, etc mandates as best practice.
We are taking the PrestaShop 1.6 codebase that has 10k modules and 2k themes as a fork. If we go changing the database handling off the bat we are going to lose the compatibility that might make us successful. We aren't a project starting from scratch with unencumbered code. We need to maintain compatibility to be successful in the beginning. We are springboarding basically. You are wanting us to take the springboard away and just jump.
since 1.7 is already breaking backward compatibility.. maybe it was an opportunity to do it right.
After that we are going to pool our knowledge, resources, and community to figure out the path forward. I will be totally honest with you, I am half developer half CSR person. I hear what my clients want and I try to make it happen. I am not the only person in on this though. I am one of many and very flexible. We are going to do a rewrite after we have stabilized things and we are going to do it right. We are going to look at the options out there and figure out where to go.
At this point it looks like I am leading things. I am the reluctant leader. I am the guy that realizes that my ideas might not be the best ideas and I want to hear yours. I just feel in the beginning it is about stabilizing what is there. I think if we spent 6 months rewriting everything we would lose an important window.
Tonight I am actually setting up the feature voting for our site. This is how I think things with a community need to be handled. There are going to be nay-sayers that stifle things because they are new and unfamiliar. This is always going to happen. But if we are transparent and add features by simple voting then no one can really argue with the logic. I have my ideas, but I am not the arbitrator of what will be included. I really want this to be a community project. I want the merchants and the developers to speak what they want and I want to make something that reflects the ideas of both.
So far, I've moved a lot of people, including my own online auction company, off of your platform because getting AJAX code to work reliably with it is near impossible due to lack of object-relational mapping.
I could go on and on, but quite frankly, you need to start from scratch. Right now you're just trying to slap a lot of icing on a poorly-made cake.
About the Paypal. For me personally that is a reason we are forking. Last year the company that develops the Paypal module for PrestaShop got into an affiliate fee dispute with Paypal. They released an "update" of the Paypal module that basically made every UK shop's module disappear on the checkout for customer. People in the UK had a shit fit. I mean who releases an updated module that is meant to punish users to prove a point to Paypal? Totally unacceptable.
I'm a little intimidated by the fact that if I have a problem with my store front, and start to look under the covers to fix things, I'd be hit with the full complexity of entering a new rails codebase.
A good case in point is most dedicated ecommerce platforms have one thing in common. User login and admin login is handled by a totally different system. This is a security feature. At the same time, most platforms support multiple sites or shops out of the box. Woo supports it with a plugin that was never made for ecommerce.
The lack of an MVC ... I digress. Wordpress is awesome for blogs. For something that takes money and has liability I don't want to have to read 0-day lists every day and see if I need to comment out something or update. Its counter productive to business.
The fact that it will turn off webhook delivery after 5 un-expected responses, without sending notifications of any sort, is mind boggling.
At the time, the final product was arguably a case of code that is far too split up, resulting in quite some system penalties. I get the advantage of developing that way, but I wonder if they'd have been served better by somehow writing stuff to combine libraries together for the final releases product.
Even loading the landing page on a default website used to require loading hundreds of PHP scripts. I was absolutely gobsmacked the metrics I was getting out of APC.
I have high hopes for it's future as it has some great minds behind it, but unfortunately at the moment it has some very key usability issues for developers and they are still making grand architectural changes to some components in a not so friendly fashion, so it is hard to iron those issues out yourself.
It is still an incredibly complex and cumbersome beast, and I suspect that will never change. But for complex and cumbersome business requirements it's strict structure and modularity make it a good fit.
It also has the benefit of being one of the few module/plugin ecosystems where it isn't a race to the bottom, as good idiomatic plugins are hard enough to build that it keeps lowballers uninterested and bad modules will fail a sniff test pretty quickly.
Source: Full time Magento dev.
Not only that, but it was assigned an "internal jira ticket" near the end of October and there hasn't been any further notification since.
This isn't an isolated incident. They spend a lot of money on marketing and conferences, yet the developer community seem to get less feedback than a one-person open-source labor-of-love provides. It's obvious (and has been for years) that Magento are really about the Enterprise version, and the Open Source version is really just a tip of the hat to their original legacy.
I still do consultation for it, but I no longer recommend it. I actually now actively suggest that people looking for ecommerce solutions look elsewhere.
As for us (Magento): Our velocity in handling GitHub issues and PRs for M2 has been really, really slow. This is partly due to the volume of reports, and partly due to some inefficiency in our own house. We're fortunate that we have a huge, engaged community who have continued to be patient with us - however, we know that patience has worn thin. People have work to do! Merchants have customers to please!
Starting a couple of months ago, the factors around this have started to change for the better. We've dedicated a large portion of our team to working on issue support, and I've been having calls & conversations this week which indicate further shifts for the better.
In the next week or so, I (@benmarks) and/or our new SVP of Product & Technology (Jason Woosley - @jasonwoosley_mg) will post more about the current state as well as upcoming changes.
Hopefully in the future you will be able to recommend Magento 2 when appropriate. Of course, it is on us to demonstrate real improvement.
In the meantime, my inbox is always open: ben@magento.com
Regarding your question, I hate to say it, but out of my recommendations most of my clients are tending towards either Woo or Shopify. I actually personally prefer Magento for most reasons, and still have clients who are happily trading with M1, both OS and Enterprise, but the customers on M2 feel that they've been burnt by the constant show-stopper bugs (mostly in regards to integration with other systems).
I really hope that I'll be able to start recommending M2 to clients again, as I've worked with Magento for many years and I know the system well. I feel it gets a lot of things right, but the M2 bugs have been frankly embarrassing, and have led to uncomfortable conversations with clients where I have to explain that yes, the old M1 site worked perfectly, but the new site that they're spending money on still has 3 month old bugs that I can't provide an update on, or even an ETA for resolution.
I look forward to Magento hopefully fixing the major issues with M2 in the near future.
P.S. I realised that I didn't actually post the URL to the bug I mentioned in my previous post. It's https://github.com/magento/magento2/issues/6683 ("Products updated_at field is not updating on save") which seems related to a couple of other bugs pertaining to "updated_at" fields not being modified.
One of their biggest vendors, WebShopApps, happened to write a pretty scathing open letter to Magento yesterday if you're interested:
http://webshopapps.com/blog/2017/01/what-magento-should-spen...
This is a company that just a year ago was making almost all of its revenue off of the Magento platform, and they are one of the most-respected brands in that community. Not a good sign for Magento.
I work with Magento everyday and what she says of a disparity between community and the enterprise agenda is ever so apparent.
Promises can only take you so far.
Karen raises some valid points. Others have raised some additional points as well as counterpoints:
* Kalen Jordan (Co-host of MageTalk podcast, MageMail.co creator, CommerceHero.io founder): https://blog.commercehero.io/response-1ee004f6d3c7
* Joshua Warren (CEO of Creatuity, a Magento partner agency): http://www.joshuawarren.com/blog/2017/1/5/magento-2-in-2017-...
* Paul Byrne (President of Razoyo, a non-partner Magento agency): https://www.razoyo.com/blog/2017/01/07/2017-starts-rage-apol...
If anyone reading this thread is curious about Magento in 2017, I recommend to check them out as well.
As for the CMS, Magento has recently purchased Bluefoot CMS which I take to mean they are looking at improving the CMS experience, maybe just for enterprise sigh
Business issues:
* Magento is in control of your price structure. You will structure your prices in the way that Magento allows, or you will suffer. Our client was not happy with the price calculation, so we spent hundreds of hours changing it thoroughly. Do you want tier prices for product options? Too bad. Do you want customer group prices for product options? Too bad. Do you want to set discount values as "discount this much after applying all taxes" (e.g. because your shop displays only prices after tax)? Too bad, all you can do is "discount this value on the untaxed price, plus whatever reduction that makes on taxes" or "calculate the discount amount off the taxed price, then discount that much off the untaxed price". And once you have made some price customizations, the customer will find an extension that does something to the prices and breaks your changes in a creative, subtle, and unexpected way.
* The CMS part of Community Edition is a joke without a punchline. It doesn't even have any menu module, only the ability to manage pages with content dumped in an RTE.
* Our clients were originally in love with Magento because "we can just add all these existing modules and get all sorts of awesome functionality without having to pay you for it!" We warned them that that was a pipe dream, but they didn't listen. Now they have several thousand hours worth of custom development on top of Magento 1.x (95% of it written solely by me, no bus factor problems with that) and they're still asking for more. Last I checked, the end-of-life for M1.x is planned in December 2018, and the client has no plan for what to do then.
Technical issues:
* The database API has an "you want it, you got it!" mentality - if you tell it to add a unique index and MySQL refuses to because existing data is not unique, the API will parse the MySQL error message to identify the duplicated fields/values and delete the duplicate rows silently. You will get your index, but you might no longer have all your data. [0]
* The model classes store nearly all the in-memory data in an untyped dictionary. You can call $model->setFoobar('12345') and later $model->getFoobar() to get it back - all unknown method calls get forwarded to a "catch-all" method which treats the method name as a key into this dictionary, and gets/sets a value of that key [1]. Most of the time, these calls are unannotated, so IDEs can't make any sense of them (see the "Undefined method" part in [2]). This magic is also a performance issue, so they make optimizations like [3] by inlining pieces of the catch-all handler code for commonly-used data.
* EAV models. In theory, a workable idea, and you can even make your own EAV models if needed. In practice, you need to spend a lot of time in the debugger stepping through the code to figure out what code in the Product or Customer classes needs to be copied into your custom EAV model to make it work right, because the core EAV model doesn't have half the needed functionality.
* Misleading code comments and annotations. Nothing like finding a method whose phpdoc says it returns a class that does not exist in the codebase.
* XML configuration jungle:
* Module configuration and theming configuration is based on heaps of XML that has no schema. Module configuration combines XML documents in the "there can be only one" manner (if two documents have XML nodes with the same path, the second one's value overwrites the first one), specifically so modules can change each other's configuration.
* Theming layer operates on "blocks", which are basically a PHP class with a corresponding .phtml template file. These blocks are defined, managed, and composed through XML files. You can even encode instructions like "after creating this block, call its method foo()" in the XML. If your theming doesn't seem to take effect, you get to step through the loader to figure it if it's not loading your file, if some file loaded later is giving different instructions, or if you placed your code in the wrong place in the XML structure. Or if there's some extra XML configuration in the database specifically for this category/product/CMS page. Happy hunting!
* Using third-party modules and themes is a russian roulette:
* Magento includes a "Developer Mode" where php notices and warnings are turned into exceptions like in sane languages. However, lots of modules and themes have never been tested with this setting on and they cause faults on every page load - either you have to disable the Developer Mode, or fix this third-party code.
* Some modules are well written, some do crazy things completely at odds with Magento workflow (e.g. an extension to set custom tier prices that calculates them when you load the product from the DB and ignores the precomputed price index in the DB), some are downright broken. And some of them contain gaping security holes – are you going to audit all the third-party code you include [4]?
* Magento core JavaScript is based on Prototype.js, not jQuery, so half the modules and themes bundle their own copies of jQuery and drop them in different locations. Some of them provide a configuration setting so you can disable their jQuery and use your own, some don't. I have seen a page that loaded Prototype, ExtJS, jQuery, and Angular side by side.
* As with every extendable system, some extensions don't work well together. Every module has the ability to override a Magento core class. Fun happens when two different modules want to override the same core class.
* Other
* Performance is demanding. You need powerful hardware and good caching to get good performance. And then you'll get that one extension that tanks your performance, like the Analytics plugin that loads each product in a category individually to send its data to Analytics when you view the category page.
* Security updates are fun. When you log into the admin panel, you will see a notification about a new security update. This notification shows up because a scheduled task periodically fetches a news feed, which contains security alerts, new version announcements, marketing spam, and whatever else Magento wants to show you. You read the notification, and follow a link to the Magento downloads page. There, after logging in, you can find and download a .sh file which contains both the patcher and the patch content itself. Run it to apply the patch. If the security issue is critical enough, Magento will publish a repeated reminder to apply it a few days later. Which your news feed will again pick up and dutifully display to you, despite the fact that you've already applied that patch. You will also get a panicked call from the client because he logged into the backend and saw that message too.
* Some things are just silly:
* Translation manager cannot cache the translations correctly, you get different translations for the same input with caching enabled and disabled.
* One class has both escapeUrl() and urlEncode() methods, and neither of them actually does URL encoding.
[0]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[1]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
[2]: https://imgur.com/RMxWEgR
[3]: https://github.com/OpenMage/magento-mirror/blob/magento-1.9/...
Curious to know which plugin you're referring to?
Watch this project fail in X months because the project owners care more about publicity than work.
Anyway best of luck to you.