I'm an Adobe employee, but know nothing about the real reasons for the acquisition. We focus on providing great digital experiences for our customers and their customers. Something you may not know is that Adobe is a leader in digital MARKETING. We help people create/monitor/optimize ad campaigns, we help customize website experiences for users, and we help with website creation in general-- Brackets, the IDE, Dreamweaver, all of the other creative products, Adobe Experience Manager, Adobe Analytics-- it all kind of ties together to help create an end-to-end experience for users, now especially in the commerce arena. Adobe is no stranger to web content creation.
Adobe is also focusing on AI, so if they have good talent over there, I'm sure it wouldn't hurt to have their predictive analytics tech over on our side.
Also, I'm sure Adobe wouldn't mind the large ecosystem of Magento plugin developers writing plugins for https://www.adobe.io.
I can imagine this would be a great way to identify people who could benefit from switching from Google Analytics to Adobe Analytics, as well.
I can see that. And maybe it was written subconsciously so, but the truth remains that Adobe does have its fingers in that pie, and that people think of Photoshop when they hear "Adobe" and not marketing.
They already have a few CRM like Marketing Cloud but these are SaaS. I guess they'll integrate Magento with their marketing tool suite. Magento is first and foremost an open source e-commerce "script" built with PHP so it will be interesting to see what they do with it.
Many businesses moved to integrated solutions such as Square or Shopify to simplify building shopping carts so it is possible Adobe eyes at building such services as well.
They've been doing a lot of adtech related acquisitions (bluekai, moat, crosswise, addthis, datalogix, etc). Magento fits in nicely - lots of data to potentially use/sell/take advantage of.
Adobe Marketing Cloud. AEM is their enterprise CMS product and it's super lucrative. They usually partner with elasticpath on e-commerce. This is probably replacing that relationship.
They sell AEM as a product tightly integrated with their assets acquired from Omniture (analytics and Target). Suffice it to say, it sucks. But it actually sucks less than most other enterprise CMS products.
Shrug, I have. (Used to work in an agency where it got chosen over other similar options for its integrations with various things). Plenty of devs dislike working with "boring" industries like e-commerce and plenty more like to hate on anything remotely related to PHP, but that doesn't mean there aren't people actively making a living with those tools exclusively.
I like working with modern PHP, but Magento really is a beast of a codebase. I've worked places where it was chosen as the best available (open source) option, but nobody liked working with it...
On the plus side, one of my few interactions with it left me with a bug story that's a solid intro at meetups and interviews: a frontend dev friend was stuck with a problem in Magento back when it was still pretty new and he could not get Amazon Fulfillment working with it. I dug in, did what the docs said, but could not get it working in sandbox mode. Finally, under a time crunch for him and due to schedule tightness on my end, I turned on production mode and everything just worked. End of story.
Two days later UPS knocked and I was the accidental owner of some 500 thread-count Egyptian cotton sheets I needed to mail back to my friend's client. The only time I've ever had a bug show up in real life at my house.
I don't know if people like it or not, but there certainly are a bunch of high-traffic websites that use it... which is how you end up getting purchased by Adobe. Not quite like getting purchased by Oracle, but still.
We pressed on with "M2" and are doing fine with it. The major stumbling blocks I saw for our devs were:
1) Magento sites are normally full of plug-ins. The plug-in eco-system is much less mature for M2. We had to pay to fix a lot of bugs in plugins.
2) The new basket and checkout (for instance) relies much more on client side JavaScript (it saves as you write for instance). Our seasoned Magento devs were inexperienced with that kind of application, after years of working on php server side code only.
The rest has been actually a pretty good experience.
We have run into a number of issues related to our integrations, the biggest of which was a documented behavior changing completely after a minor version upgrade, which completely broke our shit. (The behavior is that all orders go into "Processing" status after payment clears, regardless of any statuses you may have added and whatever you have set to be default for the 'Processing' superstatus. Doesn't help that the data flow for orders supremely confusing)
Also whoever wrote their JS needs to be shot. How it is acceptable to load your HTML buttons in one order and then, at the last second, suddenly switch to the opposite order. It was like all those Hawaii missile warning interface UI memes from a few months ago, except real life.
That's true, but it gets the job done. It's like Wordpress (and Wordpress/WooCommerce), nobody loves it but it powers a surprising number of businesses.
As the saying goes, compare Magento to the alternatives, not to the almighty.
If you're running an ecommerce operation that is too small to justify building a custom CMS, and can't justify paying for Demandware/Salesforce Commerce Cloud, your options are really limited.
Shopify and Big Commerce offer good out of the box functionality, but you are then stuck with their feature sets and pricing tables. Each platform taxes you in various ways. Shopify imposes 0.5-2.0% fees on transactions processed with external credit card processors. Big Commerce forces you to upgrade your plan after your sales exceed a certain threshold.
For even ecommerce companies doing several million dollars a year in revenue, Magento community edition (open source) is sufficient. You pay up front for development or design work, pay annual server costs, and can scale your ecommerce technology spend on your schedule.
Magento has given me extreme headaches at times, but once we had our site up and running it was easy to maintain and administer. The non-technical people, i.e. the people who are actually packing and shipping orders, quickly picked up using the admin panel. So, yeah, I like Magento just fine.
So far the only somewhat sane alternative is prestashop.
At least I don't worry what breaks this time on a security update, which is a real PITA with magento.
For updates to magento shops I schedule time, for updates to prestashop I press a button..
We actually used to run our site off of Prestashop. The biggest reason that I saw to switch was because of the lack of integrations with some of our operations tech stack. For example, Freshdesk has an official extension/add-on for Magento, but on PrestaShop the only add-on is a $39.99 option made by a 3rd party developer.
Prestashop is probably easier to administer than Magento, but that comes with tradeoffs because of its smaller developer ecosystem.
Prestashop in my experience is not anywhere close to sane. The code is a shitshow, the transition to symfony/twig has been slow and chaotic, and even if you try to help fix issues you are met with nothing but silence.
I'm not saying magento is better, but prestashop isn't in any way sane.
Sylius : the Symfony framework ecommerce offering is the only platform we've found to offer the proper combo of features, scalability (this was huge), flexibility, true framework backing in symfony, and a proper deployment model.
It's a very exciting platform finally after having so many fall short for so many reasons; we really liked Lemonstand v1 but hated being forcedinto thei SaaS model which totally killed our app extension bundling applications business model.
So, seriously check out Sylius.
If you have a small to medium sized shop, WooCommerce (now owned by Automattic) is a better solution and easier to deal with than Magento. For larger sites Magento is the go to, until you reach the threshold of a much more expensive paid solution.
I only briefly experimented with WooCommerce, so please correct me if any of this is incorrect.
My general issue with WooCommerce is being locked into Wordpress. I’m not a Wordpress expert, and it’s very difficult to determine when a security vulnerability (http://www.cvedetails.com/vulnerability-list.php?vendor_id=2...) is serious enough to justify upgrading my WP version, which may break compatibility with not-yet-updated plugins.
Small and medium is also in the eye of the beholder I guess. If you’re selling less than a dozen items, with no need for configurable products, advanced pricing rules, bulk discounts etc, then Magento is probably overkill.
Simple fix, always keep your Wordpress up to date, I don't know why people in the CMS world have fallen into the trap of not upgrading. Drupal for example is notoriously hard to upgrade on point releases, Magento isn't much easier. Wordpress is fairly seamless, couple that with Cloudflare and your site is pretty secure from attack.
I also don't see how you can be "locked into" Wordpress either, it's actually one of the easiest CMSs to migrate into and out of. It gets flack for being widely used and running on PHP (so does Magento,) but it's widely used for a reason.
So, for an extension like Shipstation, which is how many ecommerce sites manage postage and labeling, I see that they haven't updated their extension since last year: https://woocommerce.com/products/shipstation-integration/. The listed compatibility is with WooCommerce 3.3.
Put yourself in the shoes of an ecommerce site operator. When a Wordpress minor release like 4.9 comes out, do I upgrade or not? How do I balance the security patches with the potential of breaking a critical part of my workflow?
EDIT: I meant WC 3.3. 4.1.19 was actually the plugin version
Same. I'd stop somewhat short of saying "I like Magento just fine." - but I'd admit to having continued to select it as the least-worst option, even after having been burnt by it several times previously.
If you're doing several millions in revenue, you should probably be using Shopify and not dealing with the costs to host, secure and maintain Magento. Magento is mid cap from $10 million revenue to $100 million in revenue.
Anything above that $100 million you're running your own WMS/WCS, OMS, CMS etc.
I'm not claiming that it's one size fits all, but I think recommending a platform based off of revenue size is foolish. In my particular case, we maintain warehouses in 3 different states. Shopify does not offer a viable solution for managing multi-location shipping and inventory management. We also have a hybrid B2B/B2C business model, so several of our distributors log into the site to place purchase orders, and we can create quantity discounts and group based pricing. None of this is possible in Shopify. I would be stuck paying a monthly subscription fee for something like this: https://apps.shopify.com/customer-pricing.
On the other hand, MVMT Watches did $60 million in revenue in 2016, and is still on Shopify. Bombas socks did $50 million in 2017, and is still on Shopify. For many companies that sell a focused class of item, Shopify may well be the better solution for them.
Somewhat tautologically, the best ecommerce platform is the one that best suits your needs.
It seems like many developers prefer this newer Rails-based shop to Magento in terms of being able to customize. I've been contemplating moving a medium sized shop to it given that it seems relatively easy to customize, but nobody has mentioned it here.
Anybody have any experience or input on either of these?
I picked up Spree in 2015, and still build with it on a weekly basis.
The platform and its ecosystem both have ups and downs, for example the order system is quite complex[1]. For another I have yet to find a perfect way to architect complex extensions.
Most of Spree's power lies in its models. In hindsight my advice to myself would be: start with spree_core, modify the API (I like using cart api's on the frontend) and replace the backend/frontend entirely.
Glad to hear the models are sane. I'm trying to get off a horribly convulted system with many issues and have been keeping my eye on Spree for years. Any thoughts about choosing Spree vs Solidus at the point?
I basically have custom frontend everywhere including some of checkout and account pages, so I mainly need to replace cart and payments and checkout and may try to integrate at the API level and handle all UI custom.
I have a bunch of requirements that may need plugins:
- Volume pricing
- Personalization such that some products can exist in the cart multiple times, but each item has a unique ID
- Upsells / add-ons for personalized product. I currently handle this hierarchy outside the cart, but it's brittle. There are thousands of different options per product and they change all the time. Quantities of these have different syncing rules in terms of their quantity vs their parent combined with quantities from an external data source e.g. address book.
- Social login, potentially adding login and payments with Amazon. Pondering if it'd be best to go with Auth0.
Promotions seem really powerful which is good, because I use them heavily and would want to add custom ones.
Any thoughts, insights, suggestions given these goals? Looking to support 100k products and millions of promotions.
Hmm. The one thing that stuck out to me was "millions of promotions" - how are you quantifying that?
Are you developing/looking to develop this yourself internally as a retailer, or are you building this out on behalf of a retailer? Some of the other bits you've mentioned certainly sound complex (although this might be how you've approached these combinations of options and products), but not outside the realm of a Spree/Solidus or Workarea style implementation.
I'm developing internally as a retailer. Having millions of coupon codes or gift cards is important for sales and doing deals with partners or sites like Groupon. Then, with many items across many categories, as well as tons of add-on options, application and stacking of multiple rules needs to be powerful, but it seems like Spree now provides all the tools to make that manageable.
Sounds like an interesting project. I picked Spree over Solidus because Solidus is based on version 2.4 of Spree and I was already on version 3.0 at the time. The split was due to the company behind Spree being bought out but luckily for us another company stepped in and Spree is now moving quite quickly..
Have done personalised line items in the past, when adding to cart there is a function that checks not just the variant being added but the options being added with. The comparison hooks for these options are designed to be extended, so that one should be relatively easy. Complex price changes on orders/line items can be handled via adjusters. These also hook into orders and are very flexible (although I haven't had to build any).
Have also build custom integrations to sync inventory with an external source using webhooks, since everything is fundamentally just Rails underneath it's as easy as you might expect.
No experience with changing the auth system, but since there is a separate plugin for the authentication (spree_devise) I think the intention was/is to make it easy to swap out if needed. I don't know how easy that would be though. There is no address book out of the box (just a save last used address feature), that's one of the features I am finally adding now.
I think you could go one of two ways with this, either a) keep your code light using decorators etc and try to do everything the 'Spree' way so that you can benefit from an easy upgrade path or b) fork spree entirely and manually bring in updates from upstream. I am slowly leaning towards b) because Spree has some design decisions that are incredibly powerful but also make everything much more complicated. Mostly I am referring to the ability to split shipments on checkout here.. I spent hours tracking down a specific line that was rejecting a shipment once. I gave up entirely and replaced spree_frontend early on, but I am mostly a frontend developer.
Thanks for insights here. Funny you mention split shipments because that's a current tricky area for me and one I wish my commerce system could handle. I create potentially many shipments from orders right now based on inventory, the types of add-ons chosen, where the buyer is, and current workload. Unfortunately right now, this is all done in a separate system so it's difficult to provide customers with good visibility on shipping times of each product up front.
Also a note around the number of products, I think you would be okay, promotions - see other comment, dynamic adjusters would be fine I think.
One thing to watch out for is Spree leaves cart level orders in the database, and deleting an order is not trivial. I have a cron job that deletes incomplete orders over a certain age, made after I realised ~90% of the database size was made up of abandoned cart data.
Thanks that's good to know. Since I'm selling personalized things I'd probably keep all of the abondoned carts around so they're still there when people return. My current database stores all the abandoned carts in serialized blobs with Java objects so anything is better than that for maintenance!
Exactly this. We don't have the budget or the staff to build a custom CMS or ecommence solution, or to pay for the "big" players. Magento is actually great. With some optimizations, it can be quite fast- our site is pretty quick for what it is. Its also very extensible which makes it great to customize for our needs. And yes, the non-tech people can use the CMS part pretty easily.
Shopify is a more modern implementation - easier to configure and done so in a manner that is not new-user unfriendly. Which is not to say it's friendly, just not totally unfriendly.
Note: I got turned down by Magento over a year ago. Not sure if I'm still biased or not.
I didn't assume that. My hunch is Adobe wants to create something similar to Shopify but for larger mid-sized and true enterprise entities. Sure many use Shopify but not necessarily because they want to.
They bought demandware nearly 2 years ago for just slightly higher which has ecommerce. They just recently ended Business catalyst which was a POS. I guess they magento is the key to taking on big and small ecom sites in the future with this POS.
I know it sounds implied but he didn't say customer service had access to plain text password, just that he verified it over the phone. You can surely do that with hashed password but it's still not a good practice.
I was not enjoying Magento and my password was something like "MagentoSuck$"
I don't remember who I was talking to exactly but they said something like "and you're logging in with the username <whatever> and the password (fading awkwardly) MagentoSucks..."?
"Last time I interacted with Magento, one of their customer service people"
That sounds to me more like they were dealing with the Meganto support portal rather than the Magento ecommerce software itself - a quick peek right now suggests that's Zen Desk. I don't know if ZenDesk admins have access to cleartext user passwords, or if Magento's ZenDesk agents regularly ask people for passwords and have a means of verifying them - but it's not a good look either way.
It's "smart" EAV[0] Database schema gave my colleagues so much good time. I do not know how it became in more recent versions, but at the time I distinctly remember them dealing with abysmal DB performances and completely gibberish auto-generated queries.
In one case, I had to manually dig through the DB and write an ad-hoc query to extract data that was needed for reporting, otherwise the software would start doing a gazillion of round trips between a DB lookup, an AS-level computation, another DB lookup...
That DB design tasted of super-mega-premature optimization, in which the developers wanted to guarantee extensibility at all costs, foregoing in the process the design of an actual data model.
They had to adopt EAV database schema model because they want to design a schema that can be as generalized and flexible as possible. Obviously performance is the trade off. As a result, every Magneto shop has to use multiple layers of caching, which complicates the maintenance of Magneto, an open-source ecommerce off-the-shelf platform that's supposed to be easier than homebrew your own, ironically.
Avoiding the EAV model while still being flexible (e.g. sparse attributes for any variety of products) is one place where the JSON datatype really shines. Throw your non-standard attributes into a JSON object and use the native DB functions to filter accordingly. In Postgres and MySQL 8 you can add conditional/functional/virtual indexes to keep things speedy. Maybe Magento will one day take advantage of these features.
That is great advice. Where you are talking about just allowing multiple attributes for a product catalogue you can also do 'EAV light' and have a 'user-defined-attribute' table that goes
Sku, attribute_id, value
and another table with a simple list of attributes. I have seen this in production (not in Magento) for a product catalogue and performance was satisfactory, queries were fairly simple and maintenance was easy. I think I prefer your JSON solution but this keeps very much in line with standard relational thinking.
I first tried Magento back in 2008. Past 2000 products it was unusable. We needed to have 50000 products. Magento was out and we built our own store. So what is "lots of products" now ?
memcached had already been around for years before Magento - if they needed an example of how to do a key/value store.
We we using that back when it was a LiveJournal Perl project, probably late '90s. There were a bunch of "persist memcached to disk" projects too - from memory we used a Java thing called Prevlayer or something...
Having said that, I too mis-used MySQL as a key/value and EAV store back then, because it was the pragmatic choice at the time. If some of my work from the late '90s and early 2000s had grown into platforms still being used today - people would probably be questioning my sanity for choices like that as well...
Prevayler is an open source object persistence library for Java. It is an implementation of the Prevalent System design pattern, in which business objects are kept live in memory and transactions are journaled for system recovery. Prevayler is the simplest and fastest way to provide ACID persistence for your "plain old Java objects".
Since at this time you seem to be the first user of the f word on this thread, it seems like a good time to say that me and a lot of my database friends and colleagues use Magento as a replacement for it. So you could rewrite that bit of your comment as "what the Magento?" and it would not lose meaning for us!
Last year, I started writing my own E-Commerce solution after being frustrated with Shopify [1], I obviously referred to some well established projects to design on top of. The first one was WooCommerce (PHP) and the second one was Magento. After digging up a little bit [1], I was convinced that the way these solutions made money was through complexity. The more complex the solution is, the more customization that's involved.
Believe me, when I tell you that your own E-Commerce solution built on top of rails/node/phoenix/etc. will be much better than these open source OTS solutions that have several hidden gotchas. IF at all I'd recommend something, it'd be Spree.
Funny you should mention this, I make my living building sites with Shopify, Craft Commerce and Spree. After experience with Magento, Woo Commerce, Open Cart and many others these are the ones that give me the fewest headaches on a regular basis.
...Not to say they are perfect. Spree has an absolutely crazy order system[1] and Shopify is a pain to extend.
Strangely the Venn diagram of platforms that are extendible/fun to code and the ones with a great community/ecosystem don't seem to have much overlap.
Can you talk more about your Craft Commerce experience? I really like the CMS but I’m nervous about Commerce because there are so few integration plugins.
Sure, I tried it over Shopify because I wanted the ability to have complex pricing (well over 100 per product). I built a system that allowed for the ability to have dynamic prices based on the base product price + a combination of selected options.
Craft has a fairly sane way to do plugins. Commerce itself is a well written if sometimes obtuse plugin, which is handy because some of the documentation isn't great (the new version - 3 - looks better). It is an EVA database, but it's simple to navigate and debug. There's some fairly powerful ways to handle loading content.
In summary I'd say have a poke around the commerce plugin, you can run it for free unlicensed. It has a growing ecosystem of plugins, which is nice coming from Spree. Oh and support is pretty good too.
I’ve made a pretty good money over the years with Magento and even though I’d still recommend it to clients (since there’s no better alternative) every interaction with it is painful. To the point where I mentally add an “insalubrity” tax to every Magento invoice I make.
I don’t know how to feel about this accquisition. I already depend on Adobe a lot more than I’d like to, and this makes it no better.
Out of curiosity, are you familiar with Workarea? Seems to fit pretty squarely in the 'better alternative' category,at least for medium-sized and up companies.
Yet Sagepay (which was huge in the UK) relies on a third party plugin (Ebizmarts). We started getting duplicate payments randomly. It never got fixed. Now we use Braintree
I don't know if you've had a look at the other comments in this thread, but if Magento was actually unbeatable, let's just say I'd still be coding in PHP today.
So a company whose fantastic products are also known to take forever to load even on most performant machines, acquires a ecommerce that looks good on the outside, but it is pain to run in every scenario :). Kind of make sense in some weird way.
Adobe attempted an acquisition of Hybris Software, a Java-based e-commerce platform back in 2013 (see first link). This would have meshed well with their Adobe Experience Manager, their CMS solution (an integration already existed, and was also based on Java/Spring). SAP offered Hybris the opportunity to operate independently for two years, and Hybris was acquired by SAP.
What is surprising is how AEM and Magento will integrate, considering that AEM is a Java/Maven based CMS and Magento is PHP.
(And yes, the article doesn't seem relevant, but contains an important reference)
They have actually had a partnership/integration for ~2 years. Basically it comes down to using AEM as the "Glass" in front of Magento. Basically just using Magento as an API and doing all of the front-end with AEM. I know there are a couple of big sites that have gone this direction, but I think the M2 API is still not feature rich enough to make it work easily.
SAP acquisition makes more since they sell ERP software and there is a synergy between back office and commerce systems. I still don't understand Adobe acquisition since they do analytics and creative software.
eBay/PayPal bought and sold Magento before this. When a payment processor that could embed and make its' offerings the optimal experience within a heavily-used ecomm platform decides to ditch it, I think you have a dud.
Adobe is looking more like a holding company trying to grow their membership offerings than a company building a cohesive product. It's similar to how Microsoft is acquiring successful companies but having a hard time incorporating them into their ecosystem (Skype, anyone?).
I don't see this going well for either Adobe or Magento. Remember when Adobe acquired Macromedia and killed Fireworks? And then Sketch came in and neatly filled the void? That's kind of what Adobe appears to do to companies.
I'm not saying Adobe is bad, but their diverse portfolio of products won't be well integrated for years and in that time, there is the possibility of killing a brand simply because it does not keep up with time (and competition).
Adobe's behavior makes me think more of Oracle than Microsoft:
Acquire a product with a competitive moat, reskin a year later but change no features, attach an enterprise sales force to it to wring the hell out of every last subscription dollar you can get, and then maybe release a few substantive changes when sales begin to slide.
We took our company off Magento enterprise and onto community. We paid to have the features we wanted from Enterprise developed on community exactly because there was no guarantee that the price of Enterprise wouldn't get racked up every year. Feeling good about that decision today
nah, Adobe's just seen the massive benefit to their annual bottom line for anything with a subscription model, so it seems a neat fit to bring in a subscription eCommerce brand which is, in a practical sense, the nexus of 'Creative', code and web application.
Frankly, I now hate Adobe with a passion (because lock-in rip off), so I don't wish them any luck.
This acquisition has piqued my interest moreso than your average bear because I work for a major retailer that just so happens to be heavily invested in Adobe Experience Manager (AEM). We are using AEM strictly as a CMS and are otherwise heavily invested in Oracle Endeca to drive commerce from a search/nav perspective. And then there's the whole payment and order management issue which we handle with custom, in-house solutions.
I'm a little scared to hear all the horrible experiences with Magento because I'm a developer on our search team and working with Endeca (or any Oracle product for that matter) is an absolute nightmare. I flat out hate Endeca. We'll be due for a replatform in another few years (once the business gets sick of us trying to bolt on big data features to Endeca, which just wasn't built for such). I can imagine us going the Magento route since we already have hefty contracts in place with Adobe.
I've tried to pitch a custom solution based on Elasticsearch (or Solr directly) but my director and VP don't want to hear about anything that involves building various business user UIs from scratch. Endeca provides a (sigh... Flash based) UI that gets the job done, and on top of that we have several legacy apps with (can't believe I'm saying this in 2018) UIs written in classic ASP.
Other than Shopify or Workarea, are there any platforms you, the ever-full-of-knowledge gurus of HN would recommend? I really like both of the aforementioned products because they give you a lot of useful UIs out the box (in addition to the capabilities of the platforms themselves), but they also give you a lot of content management and we don't need that.
It's a smart move for Adobe I believe. I really can't see how the overlap of customer base for AEM / Magento will be, also it will be interesting to see if they start to do more b2b or b2c eCommerce. It is an interesting time in the space, strong CMS adding eCommerce, and strong eCommerce adding CMS. It's highly likely that Salesforce / Commerce Cloud will expand into the CMS space and possibly more consolidation of platforms.
There are some abstract systems like Moltin.com that offer eCommerce APIs
Platforms like BigCommerce.com / VTex.com / Miva.com / Volusion.com are also pretty popular.
Then you have some end to end ones like Coredna.com* that offer B2B, B2C and CMS.
Awesome reply! This is why I love HN. I'll be sure to investigate all of the options you've provided, including your own company. It takes a lot of integrity to list your own product last and include a disclaimer to boot. Kudos!
Hey! one of the founders at Moltin here. Thanks for the mention @blackdogie, always a nice surprise to stumble across! Coredna looks interesting (nice explainer video!).
@jsntrmn we often see the need to de-risk technology choices for decision makers at larger retailers which can sometimes be in conflict to what a developer looks for when selecting a tool or service. We're trying to get the right balance at moltin as we think both voices need to be at the table.
Happy to chat with either of you if you would like to share learnings/experience or if I can help in any way, just drop me a message adam@moltin.com
When picking a platform, it's generally not about the feature set, as to why one is chosen over another. Often it's service : price, flexibility (integrations or future expansion), or just how the business operates in general. Best of luck on your reach. Feel free to reach out if you have any questions.
I totally understand the fear your VP have. It’s much harder(expensive) to find developers who have to manage their own ES or Solr instance instead of just making minimal enhancements to a base product that “works”.
It sounds like solid risk management which is what most companies (large) end up hiring people at that level for.
If you’re wanting to build newer things with newer technology then you should find a new role.
I suppose you've hit the nail on the head with your final sentence. I do agree with you, though, that my VP is making the appropriate decision given that we're a large enterprise.
At the end of the day, whether I'm a cog in the wheel of a huge machine or a decisive voice at a small startup, the engineer in me just wants to see the best solution realized. I guess that's why I still care, when in reality, I should probably be considering a move elsewhere.
Drupal 8, plus integrated ElasticSearch (so you don't have to build UIs and can also integrate search into displaying collections generally), and Drupal Commerce if you like.
Have you worked much with D8 Commerce? I know it's spoken of highly in the community but after tolerating it since my first deployment of that combo in late 2015, it still feels half baked at best and almost completely undocumented relative to other major Drupal projects.
Why this very evening I'm having to manually re-input authorize.net details because they updated the module with a very poor upgrade path.
Well it's always been under resourced and you could fairly say it lacks product/commercial maturity so will have many rough edges and gotchas, but at the same time it's a very complex problem space where all of the solutions have drawbacks - so I'd look more at what the differentiators are, since we have to endure pain in any case.
So for example, with shopify you know it's all going to be click and build and largely configurable by commerce owners. Ease of use and a generic set of capabilities that scale across its userbase.
With Drupal Commerce, you know you are going to have a completely extensible open source system which leverages very powerful existing Drupal components such as entities, views, users, rules, search. There isn't really anything else like this.
A long time ago, I saw one very big d6 project (with insanely huge spiky traffic) which recognised this and used d7 commerce as a separate standalone system which sat on the back end integrated with the d6 site. This was after assessing Hybris, Magento, and Demandware as alternatives and understanding that they would require far more bespoke coding and have higher maintenance costs to come anywhere close to the very very specific and high spec requirements this particular site had.
Having worked on Hybris and Magento and a few other eCommerce platforms, Hybris is the best of the bunch. When I say best only relatively...it has its own headaches but at least its not as horrific as Magento
157 comments
[ 3.4 ms ] story [ 231 ms ] threadAdobe is also focusing on AI, so if they have good talent over there, I'm sure it wouldn't hurt to have their predictive analytics tech over on our side.
Also, I'm sure Adobe wouldn't mind the large ecosystem of Magento plugin developers writing plugins for https://www.adobe.io.
I can imagine this would be a great way to identify people who could benefit from switching from Google Analytics to Adobe Analytics, as well.
Many businesses moved to integrated solutions such as Square or Shopify to simplify building shopping carts so it is possible Adobe eyes at building such services as well.
The main recent adtech acquisition by Adobe was TubeMogul, in 2016.
They sell AEM as a product tightly integrated with their assets acquired from Omniture (analytics and Target). Suffice it to say, it sucks. But it actually sucks less than most other enterprise CMS products.
I think Magento is "fairly priced" priced at ~10% of Shopify's valuation
That's good enough in my book.
And way better than some BS startup that gets billions for "uber for cats" and "self-erasing dick-pics for teens".
Two days later UPS knocked and I was the accidental owner of some 500 thread-count Egyptian cotton sheets I needed to mail back to my friend's client. The only time I've ever had a bug show up in real life at my house.
And don't look to closely at its chosen database schema...
1) Magento sites are normally full of plug-ins. The plug-in eco-system is much less mature for M2. We had to pay to fix a lot of bugs in plugins.
2) The new basket and checkout (for instance) relies much more on client side JavaScript (it saves as you write for instance). Our seasoned Magento devs were inexperienced with that kind of application, after years of working on php server side code only.
The rest has been actually a pretty good experience.
Also whoever wrote their JS needs to be shot. How it is acceptable to load your HTML buttons in one order and then, at the last second, suddenly switch to the opposite order. It was like all those Hawaii missile warning interface UI memes from a few months ago, except real life.
If you're running an ecommerce operation that is too small to justify building a custom CMS, and can't justify paying for Demandware/Salesforce Commerce Cloud, your options are really limited.
Shopify and Big Commerce offer good out of the box functionality, but you are then stuck with their feature sets and pricing tables. Each platform taxes you in various ways. Shopify imposes 0.5-2.0% fees on transactions processed with external credit card processors. Big Commerce forces you to upgrade your plan after your sales exceed a certain threshold.
For even ecommerce companies doing several million dollars a year in revenue, Magento community edition (open source) is sufficient. You pay up front for development or design work, pay annual server costs, and can scale your ecommerce technology spend on your schedule.
Magento has given me extreme headaches at times, but once we had our site up and running it was easy to maintain and administer. The non-technical people, i.e. the people who are actually packing and shipping orders, quickly picked up using the admin panel. So, yeah, I like Magento just fine.
At least I don't worry what breaks this time on a security update, which is a real PITA with magento. For updates to magento shops I schedule time, for updates to prestashop I press a button..
Prestashop is probably easier to administer than Magento, but that comes with tradeoffs because of its smaller developer ecosystem.
I guess that it wasn't so much that the add-on came at a cost, but more that it was:
a) a 3rd party developer
b) the only option
As you said it was just one of your issues.
I'm not saying magento is better, but prestashop isn't in any way sane.
My general issue with WooCommerce is being locked into Wordpress. I’m not a Wordpress expert, and it’s very difficult to determine when a security vulnerability (http://www.cvedetails.com/vulnerability-list.php?vendor_id=2...) is serious enough to justify upgrading my WP version, which may break compatibility with not-yet-updated plugins.
Small and medium is also in the eye of the beholder I guess. If you’re selling less than a dozen items, with no need for configurable products, advanced pricing rules, bulk discounts etc, then Magento is probably overkill.
I also don't see how you can be "locked into" Wordpress either, it's actually one of the easiest CMSs to migrate into and out of. It gets flack for being widely used and running on PHP (so does Magento,) but it's widely used for a reason.
Put yourself in the shoes of an ecommerce site operator. When a Wordpress minor release like 4.9 comes out, do I upgrade or not? How do I balance the security patches with the potential of breaking a critical part of my workflow?
EDIT: I meant WC 3.3. 4.1.19 was actually the plugin version
On the other hand, MVMT Watches did $60 million in revenue in 2016, and is still on Shopify. Bombas socks did $50 million in 2017, and is still on Shopify. For many companies that sell a focused class of item, Shopify may well be the better solution for them.
Somewhat tautologically, the best ecommerce platform is the one that best suits your needs.
It seems like many developers prefer this newer Rails-based shop to Magento in terms of being able to customize. I've been contemplating moving a medium sized shop to it given that it seems relatively easy to customize, but nobody has mentioned it here.
Anybody have any experience or input on either of these?
I picked up Spree in 2015, and still build with it on a weekly basis.
The platform and its ecosystem both have ups and downs, for example the order system is quite complex[1]. For another I have yet to find a perfect way to architect complex extensions.
Most of Spree's power lies in its models. In hindsight my advice to myself would be: start with spree_core, modify the API (I like using cart api's on the frontend) and replace the backend/frontend entirely.
[1] https://github.com/spree/spree/blob/3-5-stable/core/app/mode...
I basically have custom frontend everywhere including some of checkout and account pages, so I mainly need to replace cart and payments and checkout and may try to integrate at the API level and handle all UI custom.
I have a bunch of requirements that may need plugins: - Volume pricing - Personalization such that some products can exist in the cart multiple times, but each item has a unique ID - Upsells / add-ons for personalized product. I currently handle this hierarchy outside the cart, but it's brittle. There are thousands of different options per product and they change all the time. Quantities of these have different syncing rules in terms of their quantity vs their parent combined with quantities from an external data source e.g. address book. - Social login, potentially adding login and payments with Amazon. Pondering if it'd be best to go with Auth0.
Promotions seem really powerful which is good, because I use them heavily and would want to add custom ones.
Any thoughts, insights, suggestions given these goals? Looking to support 100k products and millions of promotions.
Are you developing/looking to develop this yourself internally as a retailer, or are you building this out on behalf of a retailer? Some of the other bits you've mentioned certainly sound complex (although this might be how you've approached these combinations of options and products), but not outside the realm of a Spree/Solidus or Workarea style implementation.
Have done personalised line items in the past, when adding to cart there is a function that checks not just the variant being added but the options being added with. The comparison hooks for these options are designed to be extended, so that one should be relatively easy. Complex price changes on orders/line items can be handled via adjusters. These also hook into orders and are very flexible (although I haven't had to build any).
Have also build custom integrations to sync inventory with an external source using webhooks, since everything is fundamentally just Rails underneath it's as easy as you might expect.
No experience with changing the auth system, but since there is a separate plugin for the authentication (spree_devise) I think the intention was/is to make it easy to swap out if needed. I don't know how easy that would be though. There is no address book out of the box (just a save last used address feature), that's one of the features I am finally adding now.
I think you could go one of two ways with this, either a) keep your code light using decorators etc and try to do everything the 'Spree' way so that you can benefit from an easy upgrade path or b) fork spree entirely and manually bring in updates from upstream. I am slowly leaning towards b) because Spree has some design decisions that are incredibly powerful but also make everything much more complicated. Mostly I am referring to the ability to split shipments on checkout here.. I spent hours tracking down a specific line that was rejecting a shipment once. I gave up entirely and replaced spree_frontend early on, but I am mostly a frontend developer.
One thing to watch out for is Spree leaves cart level orders in the database, and deleting an order is not trivial. I have a cron job that deletes incomplete orders over a certain age, made after I realised ~90% of the database size was made up of abandoned cart data.
I mean the hardest thing, after the initial set up is on logistics and Services. What sets them apart in different level as you described?
While it was a dated system (purchased in 2009) it came as quite a surprise that it was reaching the end of its life.
I think it will be very interesting where Adobe takes this
[1]: https://forums.adobe.com/thread/2470031
BTW how much was it acquired for?
Shopify is a more modern implementation - easier to configure and done so in a manner that is not new-user unfriendly. Which is not to say it's friendly, just not totally unfriendly.
Note: I got turned down by Magento over a year ago. Not sure if I'm still biased or not.
They bought demandware nearly 2 years ago for just slightly higher which has ecommerce. They just recently ended Business catalyst which was a POS. I guess they magento is the key to taking on big and small ecom sites in the future with this POS.
My bad on demandware.. ^^
edit: (it was about 5 years ago)
Here's a 2013 version of their password hashing file[1] which should confirm that they were using the (very crappy) method back then.
OSCommerce, which Magenta was attempting to replace, had password hashing as far back as 2006.
Maybe you're thinking of a different service?
1. https://github.com/nexcess/magento/blob/master/app/code/core...
I don't remember who I was talking to exactly but they said something like "and you're logging in with the username <whatever> and the password (fading awkwardly) MagentoSucks..."?
And we both kind of laughed nervously...
That sounds to me more like they were dealing with the Meganto support portal rather than the Magento ecommerce software itself - a quick peek right now suggests that's Zen Desk. I don't know if ZenDesk admins have access to cleartext user passwords, or if Magento's ZenDesk agents regularly ask people for passwords and have a means of verifying them - but it's not a good look either way.
https://raw.githubusercontent.com/OpenMage/magento-mirror/ma...
It's "smart" EAV[0] Database schema gave my colleagues so much good time. I do not know how it became in more recent versions, but at the time I distinctly remember them dealing with abysmal DB performances and completely gibberish auto-generated queries.
In one case, I had to manually dig through the DB and write an ad-hoc query to extract data that was needed for reporting, otherwise the software would start doing a gazillion of round trips between a DB lookup, an AS-level computation, another DB lookup...
That DB design tasted of super-mega-premature optimization, in which the developers wanted to guarantee extensibility at all costs, foregoing in the process the design of an actual data model.
[0] https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80...
It's basically a modern-day approach to Serialized LOB: https://martinfowler.com/eaaCatalog/serializedLOB.html
It's the same. Expensive fast servers, lots of caching and the upkeep that goes with it.
Thanks to Magento I can add "someone tried to turn MySQL into a typeless K-V document store" to the list of crazy things that I've seen.
[0] https://kev.inburke.com/kevin/reddits-database-has-two-table...
I think a better alternative would be Postgresql which can do relational sql and what MongoDB is supposedly good for.
We we using that back when it was a LiveJournal Perl project, probably late '90s. There were a bunch of "persist memcached to disk" projects too - from memory we used a Java thing called Prevlayer or something...
Having said that, I too mis-used MySQL as a key/value and EAV store back then, because it was the pragmatic choice at the time. If some of my work from the late '90s and early 2000s had grown into platforms still being used today - people would probably be questioning my sanity for choices like that as well...
Prevayler.
From http://prevayler.org/ :
What is Prevayler?
Prevayler is an open source object persistence library for Java. It is an implementation of the Prevalent System design pattern, in which business objects are kept live in memory and transactions are journaled for system recovery. Prevayler is the simplest and fastest way to provide ACID persistence for your "plain old Java objects".
Believe me, when I tell you that your own E-Commerce solution built on top of rails/node/phoenix/etc. will be much better than these open source OTS solutions that have several hidden gotchas. IF at all I'd recommend something, it'd be Spree.
[1] I'm writing an article on this (WIP): https://medium.com/build-ideas/my-journey-of-writing-an-e-co...
...Not to say they are perfect. Spree has an absolutely crazy order system[1] and Shopify is a pain to extend.
Strangely the Venn diagram of platforms that are extendible/fun to code and the ones with a great community/ecosystem don't seem to have much overlap.
[1] https://github.com/spree/spree/blob/3-5-stable/core/app/mode...
Craft has a fairly sane way to do plugins. Commerce itself is a well written if sometimes obtuse plugin, which is handy because some of the documentation isn't great (the new version - 3 - looks better). It is an EVA database, but it's simple to navigate and debug. There's some fairly powerful ways to handle loading content.
In summary I'd say have a poke around the commerce plugin, you can run it for free unlicensed. It has a growing ecosystem of plugins, which is nice coming from Spree. Oh and support is pretty good too.
Blah.
I don’t know how to feel about this accquisition. I already depend on Adobe a lot more than I’d like to, and this makes it no better.
You would be nuts to release a payment gateway with no support for it.
I don't know if you've had a look at the other comments in this thread, but if Magento was actually unbeatable, let's just say I'd still be coding in PHP today.
I’m sure you are aware that most of the web runs on it. Wikipedia, WordPress and most other big CMSs. Oh yes, and that Facebook thing.
Adobe attempted an acquisition of Hybris Software, a Java-based e-commerce platform back in 2013 (see first link). This would have meshed well with their Adobe Experience Manager, their CMS solution (an integration already existed, and was also based on Java/Spring). SAP offered Hybris the opportunity to operate independently for two years, and Hybris was acquired by SAP.
What is surprising is how AEM and Magento will integrate, considering that AEM is a Java/Maven based CMS and Magento is PHP.
(And yes, the article doesn't seem relevant, but contains an important reference)
https://www.bloomberg.com/news/features/2017-02-09/steve-you...
https://en.wikipedia.org/wiki/Business_Catalyst
I don't see this going well for either Adobe or Magento. Remember when Adobe acquired Macromedia and killed Fireworks? And then Sketch came in and neatly filled the void? That's kind of what Adobe appears to do to companies.
I'm not saying Adobe is bad, but their diverse portfolio of products won't be well integrated for years and in that time, there is the possibility of killing a brand simply because it does not keep up with time (and competition).
Good luck, Adobe.
Acquire a product with a competitive moat, reskin a year later but change no features, attach an enterprise sales force to it to wring the hell out of every last subscription dollar you can get, and then maybe release a few substantive changes when sales begin to slide.
And Freehand, RIP.
Frankly, I now hate Adobe with a passion (because lock-in rip off), so I don't wish them any luck.
I'm a little scared to hear all the horrible experiences with Magento because I'm a developer on our search team and working with Endeca (or any Oracle product for that matter) is an absolute nightmare. I flat out hate Endeca. We'll be due for a replatform in another few years (once the business gets sick of us trying to bolt on big data features to Endeca, which just wasn't built for such). I can imagine us going the Magento route since we already have hefty contracts in place with Adobe.
I've tried to pitch a custom solution based on Elasticsearch (or Solr directly) but my director and VP don't want to hear about anything that involves building various business user UIs from scratch. Endeca provides a (sigh... Flash based) UI that gets the job done, and on top of that we have several legacy apps with (can't believe I'm saying this in 2018) UIs written in classic ASP.
Other than Shopify or Workarea, are there any platforms you, the ever-full-of-knowledge gurus of HN would recommend? I really like both of the aforementioned products because they give you a lot of useful UIs out the box (in addition to the capabilities of the platforms themselves), but they also give you a lot of content management and we don't need that.
tl;dr
You've posed a very appropriate question, one they I find myself replaying over and over as of late.
There are some abstract systems like Moltin.com that offer eCommerce APIs Platforms like BigCommerce.com / VTex.com / Miva.com / Volusion.com are also pretty popular.
Then you have some end to end ones like Coredna.com* that offer B2B, B2C and CMS.
*Disclaimer : I work for the last company
@jsntrmn we often see the need to de-risk technology choices for decision makers at larger retailers which can sometimes be in conflict to what a developer looks for when selecting a tool or service. We're trying to get the right balance at moltin as we think both voices need to be at the table.
Happy to chat with either of you if you would like to share learnings/experience or if I can help in any way, just drop me a message adam@moltin.com
It sounds like solid risk management which is what most companies (large) end up hiring people at that level for.
If you’re wanting to build newer things with newer technology then you should find a new role.
At the end of the day, whether I'm a cog in the wheel of a huge machine or a decisive voice at a small startup, the engineer in me just wants to see the best solution realized. I guess that's why I still care, when in reality, I should probably be considering a move elsewhere.
Thank you for your input!
Why this very evening I'm having to manually re-input authorize.net details because they updated the module with a very poor upgrade path.
So for example, with shopify you know it's all going to be click and build and largely configurable by commerce owners. Ease of use and a generic set of capabilities that scale across its userbase.
With Drupal Commerce, you know you are going to have a completely extensible open source system which leverages very powerful existing Drupal components such as entities, views, users, rules, search. There isn't really anything else like this.
A long time ago, I saw one very big d6 project (with insanely huge spiky traffic) which recognised this and used d7 commerce as a separate standalone system which sat on the back end integrated with the d6 site. This was after assessing Hybris, Magento, and Demandware as alternatives and understanding that they would require far more bespoke coding and have higher maintenance costs to come anywhere close to the very very specific and high spec requirements this particular site had.
Then I remember all the fun and the "good times" I had in my life building shops with Magento.
I'm kinda scared of whatever Adobe is up to here...
The "Why Magento" section is especially useless.