July 31, 2008 | Comments: (0)
Open source ECM Alfresco now emulates SharePoint
I had a long talk the other afternoon with John Newton (that's his picture at the left), CTO and Chairman of Alfresco. John previously co-founded Documentum.
If the name Alfresco rings a bell but you can't place it, perhaps it's because former InfoWorld Open Sources blogger Matt Asay is VP of Business Development at Alfresco and runs the company's US operation in Palo Alto. In any case, Alfresco is in the open source Enterprise content management business.
John was calling from England, where it was about 8 in the evening and an uncharacteristic 80 F. We started off by talking about how Alfresco has been doing, and the numbers John quoted were impressive: roughly 1.3 million downloads, about 10 thousand installations, and 500-600 paying customers. According to John, Alfresco has expanded faster using an open source model with paid services and support than Documentum did at the same point in its history with a traditional proprietary software model.
As a result of the recent EU legal actions against Microsoft, Microsoft released the specifications of all their Office interfaces. The news that John wanted to share is that Alfresco has taken advantage of that to add SharePoint Protocol support to Alfresco Labs (Beta) 3. Have a close look at the screen shot at the left of Word accessing a document in Alfresco over the SharePoint protocol -- click on it to open a copy full size.
Why does this matter? For one thing, as popular as SharePoint has become, administrators and users don't always like its restrictions. When you install SharePoint, you must also install Microsoft SQL Server, even if your standard database is Oracle or DB2 or MySQL, and you must install it on Microsoft Server 2003 or 2008. When you use a SharePoint site, you must also use Microsoft Internet Explorer to be able to access its full functionality, even if your standard desktop is a Macintosh or your standard browser is Firefox. Alfresco removes those restrictions, as well as being open source.
Alfresco Labs 3 is immediately available for download at: http://wiki.alfresco.com/wiki/Alfresco_Labs_3
Posted by Martin Heller on July 31, 2008 08:07 AM
May 30, 2008 | Comments: (0)
Put my data in the cloud? Let me think about that...
It was brought home to me recently, once again, how vulnerable we are to data loss. This time, it isn't a local hard disk crash: it is most likely a problem with a hosting provider's accounting system. In any case, the provider locked my (pro bono) client out for non-payment and scoffed at the client's receipts from PayPal. My client thinks they've paid; the provider thinks they haven't: it's a mess.
I won't post any names at this point, because we haven't yet gotten to the bottom of this. But my client can't get to its public Web site, private Web site, or content management system. If the organization weren't on a summer break, and I didn't have a local backup of most of the information on the site, it would be a disaster.
That brings up the whole issue of cloud computing. If I put my application on Google App Engine, Bungee Connect, Amazon EC2 and S3, or any other cloud, I'm likely to be storing hundreds of GB of data in the cloud. It's basically the same problem as with any hosting provider, only more so.
What happens if Amazon or Google decides they don't like my large-scale client, for some reason known only to themselves? What options would my client have? What guarantees continuity of service and data integrity?
What do you think?
Posted by Martin Heller on May 30, 2008 01:05 PM
April 11, 2008 | Comments: (0)
A security note about ftp and CushyCMS
In my first look at CushyCMS on Monday, I mentioned that "personal site already had ftp access set up the way CushyCMS expected to see it." This raises an issue that I chose to skip in the interest of brevity. A reader with a Web-based financial application has questioned me about it in email, so it seems worthwhile to discuss it here.
As you probably know, ftp is an ancient protocol by Internet standards. Many Web hosts offer password-protected ftp as the primary way you can upload content to your Web site. Some other Web hosts don't allow it at all, on the grounds that it is insecure because it sends passwords over the wire in plain text. These hosts usually offer at least one of the following alternatives: ftp access only over a secure VPN; sftp (secure ftp) access; access via FrontPage extensions; and WebDAV access.
For a Web-based financial application, opening up password-protected ftp access to the whole site would be a really bad idea: it could potentially compromise the security of users' financial information. On the other hand, opening up password-protected ftp access to a subdirectory of the site that contains only publicly available material could be OK.
That's certainly what I would do if I had a Web-based financial application and wanted to give a content editor access to a news page via CushyCMS: I'd put the news page in a subdirectory that had no sensitive information, create a password-protected ftp instance that accessed only that subdirectory, and then establish a CushyCMS connection to that ftp instance.
How do you feel about secure editing of Web content? What's your preferred access method, and why do you prefer it?
Posted by Martin Heller on April 11, 2008 08:03 AM
April 09, 2008 | Comments: (0)
Wait-listed for Google App Engine
I made a teensy-weensy mistake when I started to look at Google App Engine: I downloaded and installed the SDK and read through the Getting Started Guide fairly thoroughly before signing up for an account. As a result, I've been wait-listed. I think that means that more than 10,000 others have already signed up for the free App Engine beta. Oh well, I can still develop locally until my invitation comes through.
As about a million other bloggers have already discussed, Google App Engine feels like a direct competitor to Amazon's three Web services (EC2, SimpleDB and S3) all rolled into one Python framework.
I think it would be really nice to be able to target the Google infrastructure "cloud" for a Web application at need, just as it's really nice to be able to target the Amazon infrastructure and the SalesForce.com infrastructure at need. I can see different uses for the various platforms as currently constituted; I can also see why the choice might confuse people.
I like the choice of Python as the first implementation language, unlike many other bloggers who seem to be whining about the lack of Ruby and PHP support. I also like the way Google has given us a local server for development, and given us access to most of Django (a Web-development framework), WebOb (which provides objects for HTTP requests and responses), and PyYAML (a parser) as well as most of the standard Python runtime libraries. I think I can learn GQL without a problem: it's basically a subset of SQL.
I'll pass over the way the HuddleChat demo ripped off the 37Signals Campfire real-time chat application, for two reasons. First, about half a million other bloggers have already complained about it; second, Google has already bowed to the pressure and pulled the app.
I wonder what the 10,000 others who have already signed up for the free App Engine beta are going to do with it. In fact, I wonder what I'll do with it when I eventually get access.
What's a potentially profitable Web server application that needs great scalability, doesn't need table joins, and hasn't already been done to death?
Posted by Martin Heller on April 9, 2008 12:02 PM
TOP STORIES
ADDITIONAL RESOURCES
- Application Grid: Oracle's Vision for Next-Generation Application Servers and Infrastructure
- Do you have the power to resolve technical issues with one call?
- Take control of your content- leverage Microsoft SharePoint
- PS Series Best Practices Deploying Microsoft(R) Exchange Server 2007 in an iSCSI SAN
- Building a Highly Reliable SAN
- Enhancing Your IT Environment with SnapShots
