Open-source Sugar snared by Jobsian code block Open-source CRM developer SugarCRM has been snared by the dark, so-called brilliance of Apple's whip-tongued chief executive Steve Jobs. SugarCRM has completely re-written the mobile version of its software to work on Apple's iPhone and the iPad, dumping HTML to run on natively using Appcelerator's Titanium. SugarCRM for the …
Agree entirely. Leverage is magnification of effort or mechanical advantage. In finance it's the magnification of the effect of an amount of money. A simple example is you put 10% deposit on a house but when you sell it ALL of the profit is yours which (usually) multiplies your small deposit by many times.
Forget all the iCleverness, have they finally managed to implement a calendar that can handle multi-day events, like we've all been begging them since 2006?
I have several potential users that have dropped plans to install SugarCRM when they saw how crappy the calendar function was.
But why is the Apple on an ascendency that stuns? For why?
Maybe because one important paradigm is to design, cater and provide for you the buyer rather than create a platform so heavily influenced for developers? Maybe just maybe?
And lo! By making it so developers flood in and delight both themselves and buying consumers?
On the other hand
Apple's new not-quite-a-computer platform seems to incorporate a lot of decisions that readers think are limiting. That's just going to make it much easier for Android, WinPhone7 etc. to sweep into first place leaving Apple as the small time wacko you always wanted them to be, no?
It's far from clear that SugarCRM is banned anyway.
What's actually happened is that iPhone OS always had immigration controls. Adobe wanted to wheel in a few million Flash developers, change iPhone into Flashphone and get a free, functional Flash marketplace for small developers. Apple said NO, NO and NO. So Adobe thought they'd found a loophole in the rules and prepared a fleet of busses to drive their hoardes in. Two days before launch, Apple passed emergency legislation to block them. What part of NO hadn't Adobe understood?
A variety of smaller busses that used to come in to iPhone land also appear to be blocked by the legislation. I'm sure it will get sorted out.
What this is actually about is making and keeping the WEB open. Now that dependency on Internet Explorer has been defeated, that means removing the dependency of video and advertising on proprietary Flash. And Apple is the only one strong enough to do it for us. Thank you Apple, from me at least; sorry about the ingrates.
Yet another iPad app fail. Does no-one consider the risks of pouring money into app development for a closed platform which might not get approved by Apple? Of course not.
I don't want to be the apologist for Apple, but there's a good reason for disallowing applications built by code translation. As I understand it sending an app to Apple means sending them the source code so they can ensure you're not doing anything dodgy. Unfortunately machines and applications generally can't translate human readable source code in one language to human readable source code in another. And if Apple's devs can't review the source code easily because of this obfuscation - and there is bound to be obfuscation if the devs can recognise a Titanium or Appcelerator app - then it's bound to be rejected.
Yes, perhaps he may have to hire a developer for each platform he wants to 'support'. Firms seemed to be able to do this back in the 80s, when computers were far less common.
I'm reminded a little of Bernard Matthews and his threat - ages ago - to leave the country if a minimum wage was introduced - 'I can't afford to pay it' - really, Mr.Matthews? Can't or don't want to.
And the same thing strikes me with most cross-platform development - investors like it, because it saves them money. As a consumer, the results mostly suck, because they tend to be done with pretty much contempt for the end user - Huawei's Mac app, for instance, is written in Java, but hasn't even bothered with the one-line switch required to put the menu at the top of the screen like a native application. That is one line of code required - provided you knew you should and could do it - which most Java developers don't - i.e. you still actually need developer/designers who understand your target platforms, and your x-platform tool of choice.
Instead, what's more typical is firms want to write on one platform and for it to 'work exactly the same' on others. (How many people here who work in software development even have a single Mac or Linux client within the organisation?).
As it happens, I think this story may already be old, anyway - Apple have reviewed and accepted at least one of these toolkits as OK (I just can't see which one, but I thought it was Appcelerator).
I wonder if toolkits that convert down to C code, which is then compiled by the XCode toolchain are allowable, while the issue with the Flash approach is that rather than converting Flash-to-C and then compiling the C, it's doing it's own compilation and linking in a translation library?
Which would also give Adobe a route out - converting byte-code back to unreadable C code, and providing the source of the library.
That would make a lot of sense - if Apple want to reserve the right to bring in a higher powered Intel based iPad model, or a custom CPU, or go 64-bit - then having their development community dependent on third-party binary blobs would be a bad idea. (Particularly given Adobe's history with OS X and even 64-bit Windows and Linux support).
But if those libraries are also compilable portable source, then there shouldn't be an issue.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
