Apple

Not really my business but:

True: it is EVERYONE'S business. Working as totally closed shop and refusing to communicate or interact with outsiders is what cost Sal his job. Therefore I encourage you to repost this reply, in full or edited, to AppleScript-Users for public record.

You're absolutely welcome to direct a copy to email@hidden too; however, you will need to you cut it right down to the final section and re-edit the shit out of it until it's no more than a page and a half long. Less says more. Nail the critical points: those are the sales pitch. Leave further expansion once your audience (in this case, Apple's top decision-makers) have bought in and want to learn more.

— Under what terms are you willing to make SwiftAutomation available to Apple?

I want it right off my plate. I'm just here to write the code, and [draft] documentation. I don't want to project manage or market it; I absolutely don't want to be its official representative. As long as it's tied to me, it's weak and vulnerable, like appscript was—and look at how I crashed that and stiffed all its users.

Total ownership of the code they take over, including all responsibilities and liabilities, the right to be identified as author and whatever the hell else they like. Once Apple own SwiftAutomation outright and put it in macOS, it becomes a platform that *everyone* can trust, because it has the world's biggest vendor's official support.

Obviously I'd like them to keep it on github under their own OSS licence, because it was users' ongoing interaction and input that ultimately made appscript as good as AppleScript, and as soon as a project goes closed-source it cuts off 90% of that.

Also obviously I'd really like them not to screw up its design by trying to be clever again, because history's already proven appscript's design works and all other designs (including SB and JXA) fail, and fail hard. Appscript (from 0.6.0 onwards) was just a black-box reverse-engineered imitation of AppleScript's own internal behavior (minus the whacky compiler magic like arbitrary keyword injection and involuntary 'gets'). Still took a couple years of me using it myself and lots of users' questions and bug reports as they used it to to get it to the level where it's 99.9% "quirk-for-quirk compatible with AppleScript" (to use Matt N's description). And even now there's a few obscure details that I'm still not 100% certain about (but since appscript never got any application incompatibility reports about those they're probably okay).

But, y'know, it's _got_ to be their choice. They can't have me—or anyone else—in the back seat, dictating to them what they can and can't do with it! Worst that happens, they muck it up; the community still has the option to pick up the old pre-handover code and have their own go with it. Freedom for them, freedom for us. The rest must be cooperation and trust.

Look, SwiftAutomation code is nothing—anyone can write Swift code. What is *priceless* to SwiftAutomation is the many thousands hours of real-world working knowledge and experience that the AppleScript community has amassed over 25 years, which in turn is encoded into appscript and now SwiftAutomation. This is what makes them true 100% production-quality replacements for AppleScript: _because_ they are the product of the AppleScript community, NOT of ivory tower programmers or pointy haired managers. NOBODY understands how AppleScript works out in the real world as we understand it, because nobody else is out there in the trenches, using and fighting and winning with it every single day. If something doesn't work in SwiftAutomation that we know works perfectly in AppleScript, WE will see it, recognize it for what it is (failure), and won't rest until we've beaten out that flaw; and all other flaws like it.

Still, if SwiftAutomation doesn't look like it's 10,000 hours' worth: Good, it really shouldn't. Great product should _always_ look and feel simple and effortless (though no simpler) to consumers. I've done a pretty good job on the code (big simplification and LOC reduction compared to appscript); the docs do need a tech writer to come in and write them over again from scratch, but that'll occur further down the line once there's buy-in.

And it'll need examples too—real-world, real-application, both at-a-glance demonstrations of app scripting capabilities and actual working production scripts that anyone can pick up, use, hack on, and learn from as they like. And that'll be another one where the AS community in particular needs to step up and do the real work (don't worry, it'll have help from Swifters and old appscript vets too), because nobody knows how to make AppleScript shine and make both an impression and a real physical difference to all kinds of users' lives.

— What is your positioning for SwiftAutomation?

For us? Reboot the AppleScript ecosystem and developer user interest before it passes beyond the point of no return.

For Apple? Show that there is real, measurable, cash-in-able value in this stack.

I noted in my radar submission that Hive, Nest, Echo, Ring, ITTT, etc, etc are all beating the automation drum. To wit, there’s an automation bandwagon rolling and Apple should be on it.

Apple royally screwed the pooch after Steve left. Steve rebooted the Mac, and used it to launch the iPhone, and then used the iPhone to launch the iPad. Given this is a middle-class consumer track, and there are easily a *billion* of those, the next natural step should've been to unify the entire living room: TV, sound, the works. I go back to visit my parents, they've got *four remotes*, each with dozens of buttons, and that's just it off and on again. Let's not even mention what actually navigation channels and program listings is like for them. Never mind being able to make all these damn machines do all that crapwork for them! It's terrible! It's unacceptable! It's hard work! It barely works!

Tim's a fantastic process guy: his rebuilding of the entire Apple process chain was a masterwork. If I put him in my folks' sitting room, he'd have their whole setup hooked up immaculately, cables tidy and sleek, and even a programmable universal remote to control it all.

Put Steve in my parents' home, he'd have ripped all that kit off the wall and put it straight out the window. And then he'd come back with a six-foot wall-hung rectangle of perfect black, two long razor-thin pillars to sit on each side, and a mini iPad. And it would all Just Work. No buttons, no setup, no endlessly scrolling wanky GUI with all the usability of a glass hammer. Cut deals with the satellite people. Cut deals with the cable people. Set down the _open standards_ used to hook everything together so that everyone has full choice whether they wish to mix-n-match or use 100% Apple product out of the box.

That is the product that the iPad should've booted. Not fecking watches (luxury jewelry), not Android screens embedded in refrigerators (solution in search of problem), not "iCars" (far too ambitious for a single next step).

-----

You're a highly experienced Automator, so you'll know this next bit:

To achieve a successful, profitable automation solution, you do NOT start with a Grand Management Plan for the Grand Solution to their current Grand Problem, and the boundless confidence it will all be delivered On Time and On Budget.

You achieve it by starting at the start, knowing only that you know nothing, extracting the simplest self-contained problem that you believe you can solve quickly and which will deliver immediate, if extremely modest, payout. And then you do the same for the next low-hanging corner, and so on, until you have:

1. Justified your client's confidence that you actually can deliver your promises (i.e. always underpromise and overdeliver, NEVER the reverse)

2. Proven to yourself you understand what you're doing, so can safely make promises you know you can keep

3. Educated yourself all about the problem, the customer, how the two interact with each other, and the easy wins and easier pitfalls you can take/avoid along the way, as you gain the understanding and experience you will need to tackle the full problem

4. Lived and fought in the trenches with your actual users—so that you understand who they are and how they think and what they do, because what actually makes the difference is not how good a programmer you are, but how good a *student* you are. They are the domain experts here, not you; you need them to *teach* you their job, so that you can then bring your own specific skills to bear in making that job work better. Talking TO users—who knew!

...

Lisp and Logo folks call this approach "bottom-up development". It is the total reverse of the "top-down development" favoured by big, influental, demanding Applications Development teams, by ambitious executives on their way up, by Expert Consultants parachuted in at huge expense when the fan hits the shit, and absolutely every bloody thing that has "Enterprise" in the title.

Bottom-up development is small, quiet, undramatic, unimpressive-looking, with little to show for a long time at first. And yet, it achieves genuine, cost-effective, real-world working results—because its primary concern is not delivering the solution, but *learning the problem*, then using that knowledge to build that solution right.

Programmers who only know how to program are as useful as managers who only know how to manage, and both are even less useful than the executive who only knows how to golf—cos at least when that last bleeder is out of the office, the people who understand and actually do the work can get on with it for themselves.

Where does Mac Automation succeed most? In solving those small, simple, "trivial, boring" problems that will never make the programmers' and executives' careers, but which day in, day out, make users' lives incrementally better.

...

So why in all that's sanity would Apple now suddenly throw out their entire 25-years-worth of Automation strategy and systems and clean-slate-restart everything back on square one? What about taking a bit of time to extract every useful nugget of knowledge and experience from all those Automation strategies and systems AND USERS have already built up? At the very least, Apple should be ripping into all its extant Automation investments to pieces to discover WHY they have so failed to deliver any more than a fraction of what was once promised. Otherwise what makes them think starting all over again from initial ignorance and nothing else will arrive at a result any more successful?

Furthermore: why autopsy Automation when you can *vivisect* it instead? You learn ten times more from examining every breath and detail of the still-living organism than some chunk of meat on a table (/med-school). Automation may be moribund, but there is a very quick, easy way to revive it again. SwiftAutomation costs Apple almost nothing—a hand down the back of Tim Cook's couch will cover it—and who knows how much it could yield in return? Only one way to find out. Take the opportunity: what's the worst that can happen?

This process alone—learning from previous successes and mistakes—is more than adequate justification for Apple to keep the existing AppleScript infrastructure alive, and healthy enough they can poke it and learn more. SwiftAutomation provides it that life extension by infusing a ton of new blood. Apple has a vast App strategy and ecology covering a vast range of problem spaces and use cases, yet it has no strategy for joining those Apps together in ways that amplify their abilities and multiply their usefulness.

-----

Another near-term benefit: rediscovering Mac Automation could also give Apple's desktop/laptop platform a no-cost instant boost, right at a time iOS is starting to stutter. Whatever Apple's Grand Plan for Siri: that is going to take time; to build, to sell, to run in. Whereas the current Automation platform has two of the three already in the bag: it's just the selling that needs done. And Apple can sell, oh yes.

As word gets around that (Mac) Apps can now work with each other to do all kinds of useful stuff in all kinds of new ways, App developers will seek out new opportunities and profits in exploiting it. Help them get the word out to customers that the Mac just became a whackton more powerful overnight, and now can do stuff that other platforms can't even dream of. Yes, Mac is small potatoes next to the iOS market, but again this is not about achieving a goal in itself, but about laying the way for what comes next: discovering ideas and information that will help Apple define the requirements for a true iOS IPC infrastructure, and provide both a reference point and benchmark against which to compare that new system as it begins to take shape.

Rule #1 of Getting Stuff Done: Never do for yourself that which you can delegate to others to do for you. You are one "App"; there are a billion other Apps out there, any number of which could perform a particular task for you so that you don't need to do it yourself. This in turn frees you up to focus on the particular things that *you* are the best at, and then market those services right back to those other billion Apps in turn.

-------

Even if Apple has no long-term plans for the AppleScript/Apple event technologies (not least cos they don't translate well either to iOS nor to distributed/internet), getting their existing App developers to get their existing Apps talking to each other should yield a wealth of new ideas and value propositions, not to mention a better understanding of costs and pitfalls involved (so that whatever comes next won't repeat those same errors).

Look up Network Effect. The telephone was not useful to you because you owned one, it was useful to you because *everyone else* owned one, which in turn made it very much in your own interest to get one too.

Communication means EVERYTHING to our modern world. "AppleScript" (Apple event IPC) is Communication. The whole damn Internet is IPC! Apple's migration from professional to consumer markets does not make Inter-Process Communication less relevant or valuable: it makes it more relevant and valuable to Apple *right now* than ever before!

IPC in turn is just one small part of Inter-PERSON Communication; and AppleScript and the Apple Event Object Model, for all their many faults, are still the first and arguably ONLY IPC system designed first and foremost to serve not programmers' but *end-users'* UI/UX needs. There is a whole interaction philosophy to AEOM that is incredibly in tune with Apple's grandest Siri ambitions: a whole world of QUERIES and RESPONSES, where you—the user—say what you need, and the app figures out how to do that for you and returns the results.

...

AppleScript is a fecking goldmine; power and information hardly even tapped. SwiftAutomation is just a free supply of pickaxes for Apple to hand out across all its App developers—all the real value to them (and us!) will be in seeing what happens next.

HTH

has

[with standard apologies for length, breadth, etc]

References:
	>Re: Sal (From: has <email@hidden>)