1. HN Upvotes 2. Product Hunt Upvotes 3. Github Stars

Why? Because it's all part of their marketing con. For some software companies, they rely on the hivemind to drive the purchase of their vaporware.

https://fakerjs.dev/api/helpers.html#arrayelement

I believe is what you're looking for. The issue, as I recall, is that all of Faker is random, so what does it mean to have a `random` module namespace. We moved it out of a hope for improved clarity.

I'm one of the maintainers of MageOS (a fork of Magento) as well as a maintainer of Daffodil (a monolithic Angular PWA framework - not Microfrontends yet).

APIS are definitely the way to go but, while that's a great next step, what we're really facing is a standards issues.

Some have tried.

Schema.org as a standard is overly complex and each platform has their own API definition.

Microfrontends can be great as well, but ecommerce has a particularly special problem of requiring extremely performant SSR, so that's always a critical and complex piece to get correct.

However, this article is clearly an ad.

I haven't seen Magento - under Ebay, under Adobe, under anyone address what I think is the biggest issue facing them - total cost of ownership in comparison to the competition.

Is mageOS mostly just a maintainence mode, keep this alive till everyone can switch off (like the M1 forks that exist) or do you actually envision trying to solve some of the challenges magento is facing as a community and platform?

The goal is to migrate management of the codebase out of Adobe's hands back into the community's. Community PRs, triage, etc.

We're currently working on getting the entire CI pipeline setup in Github Actions (if you're interested in contributing, we could really use friendly faces, it's quite an undertaking). Once we're past that, we have goals that are in progress:

DevX:

1. Correct the dep graph of MageOS to be a legitimate DAG and then use nx/bazel/make, etc to compute the build graph. 2. Create codespaces/gitpods/devcontainers for easier day 1 devs. 3. Rip GraphQl out into a separate package space. 4. Create smaller more use-case specific metapackages so that you're not forced into all of Magento or nothing. 5. Maintain backwards compatibility with existing Magento packages.

UX: 1. Significantly improve overall performance.

MerchX: 1. Improve Merch documentation and make Merch docs easier to consume.

Generally to your question, we're not interested in maintenance, we're interested in taking on the burden of being a better development effort alongside a better merchant experience.

That said, this is not a sales pitch. The problem is hard, but we'd like to prove that we're harder.

The backwards compatibility is really a challenge, but I think more importantly dumping Knockout and Luma and all that insanity and going towards the Hyva route, or going more-headlessy with a good starter theme would encourage people enourmously.

Magento's frontend cluster-F is the reason we moved away from it. It was great to have such a good pricing engine, integrations pieces, currency support etc, but all of that skillset which is magento's core capability being a really well rounded online OMS is overshadowed by long and expensive turn arounds on frontend work.

Re:frontend, you're absolutely correct. Magento's frontend is a sad state. MageOS is actively looking for ways to move Luma/Blank into a separate installable package so that devs are not forced to see it at every turn.

In terms of Headless, there are a bunch of different heads at this point, but none have yet solved what I call the "upgrade-safe theme" problem.

I like what we've done with Daffodil since it doesn't impose any of those limitations that come with themes, while still handling a lot of the complexity that devs face when building ecommerce stores.

If you can make a name for yourself, you can do very well. Especially for Magento, I love the fact that I can make small change, deliver it as a composer package, and then (if the code is good enough) see the results on many brands within a few months.

It's hard to get that close-to-customer visibility anywhere else as most "cool" large scale FOSS projects are dev focused, which means your impact on the lay user is less obvious.

Mostly joking but I don't think such a bonus is a crazy idea

There's your problem.

Specifically,

> Relying on a curl'd bash script downloaded off your server seems inherently vulnerable (though this apparently applies to many vendors in the space apparently). Checksum procedures should be built into your docs, or you should be using a package registry (ala codecov-node).

Even when (if, really) people check for hash, do they check that the hash was published and fetched through a second channel? Nope, people run arbitrary code unchecked all the time, so they're just as equivalent.

Even git clone can be dangerous. Do you audit all the repo branch names before cloning? Because depending on how your shell prompt shows e.g branch names it could be used to RCE.

EDIT: by this I don't mean to excuse curl | bash and such, I just mean to highlight that the issue runs deeper, curl | bash being the unburied part.

Well, it is, because any .EXE or .MSI or .DMG I download will pass through one or more virus scanners. You can also do this by forcing users through a proxy such as Artifactory that can also do scanning of Linux packages. But it's futile to rely on automated solutions for NPM or PyPI where there is no curation of the repo so anyone can do typosquatting.