Open-source Sugar snared by Jobsian code block
HTML and back again
Magic Quadrant for Enterprise Backup/Recovery
SugarCon 2010 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 iPad is due to be announced today with a beta version of SugarCRM 6.0 updated for Javascript and that positions the suite to make massive use of the emerging HTML 5 standard, company co-founder and vice president of products Clint Oram told The Reg.
But today's debut comes as Jobs has banned SugarCRM and everyone else from accessing Apple's software through intermediary translators like Titanium on the iPhone or iPad. The hurdle popped up in the iPhone 4.0 OS SDK revealed last week. iPhone 4.0 is due to hit the phone "this summer" and the iPad "this fall" that was
Sugar moved its mobile application to Appcelerator so it could have one version of its application run on Apple, Google's Android, BlackBerry, Palm, and other devices without the need for its engineers to build completely different versions.
"I wasn't terribly thrilled when I saw this," Oram, who helped found SugarCRM six years ago, told us bluntly.
"From the ISV perspective, I really hope these guys do work it out because I'm looking at how do I support as many of the devices as I can without having to hire a developer for each and every device out there."
Oram's confident Appcelerator can work out the issue with Apple who, he said, may not have realized the ramifications of its actions. Yup, they say the Valley is a place for optimism.
Early signs are not encouraging as Appcelerator's chief executive Jeff Haynie is as much in the dark as everybody else about what happened - and why. His advice to ISVs relying on his software to tap the iPhone is to simply "hang tight." That's a business strategy you can take to the bank.
"We are not expecting it to be a road block..Regardless, from our perspective, we are committed down this path of the UI we are presenting. We will invest in building native for the iPhone," Oram said.
The new mobile edition of SugarCRM may have dumped HTML, but the company's sees HTML 5 in future of its PHP-based suite.
SugarCRM 6.0 - to be unveiled at SugarCon in San Francisco, California and due at the end of July - has been updated to suck in more Javascript to make the user interface easier to navigate. SugarCRM used Yahoo!'s YUI 2.0 and removed custom code to allow things like buttons to fade out, functions to pop up under a mouse hover, and a floating tool bar that lets you access features without having to click through lots of windows.
That's nice, but it sounds like in future Oram wants SugarCRM to combine the simplicity of the web interface with access to information and data on the PC and server using HTML 5.
He wouldn't provide details, but described a scenario that made SugarCRM act more like a Rich Internet Application - fusing web and local computing resources - through the use of HTML 5. Oram said he really liked the fact HTML 5 features offline data storage and reckoned SugarCRM's "boffins in the backroom" are coming up with the ideas.
"You will see from us in the next couple of years really leverage HTML 5 - we will focus on this as the mechanism for changing the UI," Oram said.
"Look at client/server technology at end of the 1990s and web based technology in first phase of the 2000s - the user experience at end of the 1990s was a richer user experience. But things have been catching up and you can build as dynamic user experience in HTML 5 as you could in fat client environments, having all the usability of a richer user experience but none of the down side of managing the updates of the application." ®
COMMENTS
Re: Grrr!
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.
Haha
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.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Agentless Backup is Not a Myth
Top 10 SIEM Implementer’s Checklist
Steps to Take Before Choosing a Business Continuity Partner
