+1. I got excited but https://lasuite.numerique.gouv.fr/ doesn't seem to be in English or any other European language. If you guys are hoping for Europe-wide adoption, start there.
Scrappy co-creator here. As an old-school Mac user (from the days of desktop publishing) I do know the difference between hyphen and en-dash and em-dash :)
We used AI sparsely for wordsmithing and definitely not for generating the text. Believe me, putting it together was a lot of work (Pontus did the heavy lifting).
Scrappy co-creator here. I fully agree that software longevity is important. We designed Scrappy with a local-first architecture, so we have no traditional backend. Our only cloud dependency is a lightweight sync server. (We hurriedly added an FAQ with some more technical details after we discovered that this blew up on HN.) I believe this is an important point of distinction, both technically and financially, from most low-code/no-code tools which are SaaS'es.
One idea we had early on is the ability to save scrapps as single-page self-contained HTML files. We experimented with this but the functionality isn't currently exposed.
Being able to download a self-contained html file would be great. Not only for longevity, but also for situations where internet access may be questionable.
Scrappy co-creator here. It was a surprise to us that this blew up on HN. We've hurriedly added an FAQ to the write-up.
In regards to this question about the "Scrappy backend": Scrappy is local-first, so data is stored locally in your browser, and optionally replicated to a lightweight sync server, to help coordinate syncing between peers. In other words, Scrappy is almost entirely front-end. The only third-party dependencies are Yjs <https://yjs.dev/> and CodeMirror <https://codemirror.net/>. We don’t use any other libraries or frameworks like React. There’s no analytics.
And there's no traditional backend. The only cloud dependency is the sync server, which is a plain vanilla y-websocket-server <https://github.com/yjs/y-websocket-server/>.
Idea: everyone, anytime you hit a bug or error, post a screenshot to the social media of your choice and tag it say #applesoftware. Over time this might start attracting PR attention, which seems to be most effective at getting Apple to do anything.
I worked at Apple on Mac OS X until 2008. For QA, Bertrand believed in a lightweight touch, with dedicated QA staffing only at the top of the stack (plus a few key places like the filesystem), with the idea that any bugs will bubble up and be found through real-world usage. Most QA was informal, through heavy dogfooding.
You felt a real sense of ownership to the thing that you worked on. You worked hard and fixed bugs because it felt like it mattered, because you thought about how e.g. your mom would end up using the product, and also Steve Jobs would see it, so it had to be great. Also, teams were small. Something would involve only 1-2 people, and then we would look over at Redmond and they'd have dozens of people working on the same thing. The need-to-know secrecy was not just for PR value; it helped keep circles of communication tight, cutting out a lot of noise, so you could just focus. The organization was stable (and relatively flat, around 5 levels from junior engineer to SJ). I think in my 9 years or so there, there were no major reorgs. Avie phased himself out and retired, and Bertrand moved up. The only major disruption was when the iPhone project happened.
Release cycles were annual. Throughout most of the release cycle, it was pretty free up to each team and engineer to decide what to work on and how to prioritize it. Near the end of a release, it would get more and more strict on what you were allowed to change, up to the point where Bertrand sometimes would even ask to see code diffs.
I don't really know what is going on over there now. They have moved to a more agile approach, with more frequent integration checkpoints. In theory this should be better, but I suspect there's less sense of ownership and more of a feeling of a software factory. But it's probably mostly to do with the fact that the systems are way more complex, both the tech and the org, with way more moving parts. Even the programming language itself (Swift) is a moving target. I know (from talking to friends) there's a lot more politics and career-building going on, the kind of corporate douchebaggery that would not have been tolerated under Steve Jobs. People are thinking about RSUs and their promotions, rather than the products.
Ultimately, I think it boils down to this observation by jwz at Netscape, that there's "two kinds of people: those who want to go work for a company to make it successful, and those who want to go work for a successful company." Post-iPhone, Apple has filled up with the latter. A majority of the people at Apple now didn't work there under SJ, and the senior management who did experience that is now aging and retiring. At least from the outside, as a customer and end-user, it feels obvious that the founder-led product-obsessed culture is gone.
I worked at Skype from eBay to Microsoft. The clients were rewritten, sometimes from scratch, sometimes redesigned to chase after the latest UI trend. But rewriting clients didn't address the fact that the OG widely successful Skype was fundamentally peer-to-peer. There were no servers, only supernodes.
After smartphones took off, management was reluctant to ditch P2P and move to a client-server model, for both business (running servers costs money, and remember Skype mostly made money on calling PSTN) and technical reasons (P2P was at the heart of Skype). Internally, engineers had Skype working "in the cloud", but it took years of waffling (middle management was distracted by the introduction of Scrum; don't get me started about that; upper management was distracted by the company getting bought and sold twice) before slowly turning around the big ship.
By then, the A/V part of the tech had become commoditized, and plenty of free alternatives (namely FaceTime, WhatsApp, Messenger, Snapchat) had appeared on the scene, with better business models. No amount of rewriting code and building from scratch addressed that latter part. Management was very interested in finding new ways of making money, but it was also (for better or worse) very reluctant and careful in introducing ads into the UI.
reply