Live data from Hacker News

Show HN: Thirty Bees – A PrestaShop 1.6 fork

thirtybees.com

21–30 of 63 posts

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#21
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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#22
post #6

I had high hopes for PrestaShop and hope this leads to the improvements the platform needs. It's so close to being great but it was not particularly stable and their API is a terrible mess of an afterthought. 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 import…

If you're not tied to PHP, check out Spree[1] or its fork Solidus[2]. [1] https://spreecommerce.com/ [2] http://solidus.io/

Why are they both built on rails?

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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#24

Earlier quoted context omitted.

I get it, but honestly it is not in the immediate roadmap. Its really not something that people in the scale we are in are worried with.

an ORM will help you write more maintainable code in general. Every framework right from rails to symfony uses an ORM for the abstraction it brings. 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…

I understand it, but look at it from this point of view. PrestaShop 1.7 requires everyone to purchase new themes and modules. The code base is extremely messed up.

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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#25

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…

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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#26

Earlier quoted context omitted.

please please use an ORM. if yoy dont build database abstraction today... you will never be able to build it once the plugins take off. Just the fact that you can run postgresql will be a killer feature. 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 l…

I get it, but honestly it is not in the immediate roadmap. Its really not something that people in the scale we are in are worried with.

You should worry about it, and fast, as every professional and actually usable and maintainable setup uses one, and your refusal to use one, thus relying upon a patchwork of unknown stuff from unknown sources, is one of your biggest exploitable (as in I do it to clients while testing their network every day,) vulnerabilities.

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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#27

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…

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.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#28

Earlier quoted context omitted.

an ORM will help you write more maintainable code in general. Every framework right from rails to symfony uses an ORM for the abstraction it brings. 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…

I understand it, but look at it from this point of view. PrestaShop 1.7 requires everyone to purchase new themes and modules. The code base is extremely messed up. 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…

hmm.. i wont say I'm not disappointed. i thought you guys were going to rewrite a lot of the core because everything is broken anyway.

since 1.7 is already breaking backward compatibility.. maybe it was an opportunity to do it right.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#29

Can anyone suggest a good writeup on the problems with magento and the existing solutions? I honestly thought storefronts were basically a solved problem, with options like Shopify, WooCommerce+Wordpress, existing.

Have you ever worked with Magento? With 1.8+ I found customisation very tedious and unpleasant, documentation virtually non-existent, 3rd party code unreliable, and CMS functionality lacking. Perhaps it's come a long way since then but I wouldn't bet on it.

Re: Show HN: Thirty Bees – A PrestaShop 1.6 fork

#30
post #10

Earlier quoted context omitted.

Urgh. It has been several years now since I last had to deal with Magento, and nothing I've seen over the years suggests it has got any better. 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…

> Urgh. It has been several years now since I last had to deal with Magento, and nothing I've seen over the years suggests it has got any better. 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…

I've had the fortune of meeting Karen, who wrote that blog piece, and know how frustrated she's been.

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.

Post reply on HN