We're a big fan online file storage and replication services such as Dropbox, SpiderOak, or Ubuntu One. They enable mobile workers to collaborate, share files, work on the go and generally be more productive.
Due to security considerations (or data sovereignty laws) many of these services are not suitable for storing confidential or commercially sensitive material. Many of these services previously thought to be secure have now been shown to be insecure by design. (Hey Dropbox, almost a year ago, we noticed that you're using global dedupe across your customers files! When we added a common .iso file to our account, it was INSTANTLY available in our Dropbox. This 'feature' is now being exploited by file-sharer's with a tool called DropShip)
Rise of the truly open source Dropbox alternatives
Early last year we were kicking the idea around the office that we would build our own Open Source Dropbox system.
We determined that the following would be required for it to be successful and widely adopted:
- Robust Synchronization
- Secure transport
- Trivial for a techie to setup their own host
- Cross platform "hands off" client
- Well known API / interface
SparkleShare is the new kid on the block when it comes to file sharing and collaboration.
SparkleShare is a collaboration and sharing tool that is designed to keep things simple and to stay out of your way.
While we're not a fan of the name "SparkleShare", (it sounds like something you'd buy at a $2 discount shop for Halloween) we like where this project is headed.
For now at least, SparkleShare uses Git over SSH for repository storage and synchronization, thus fulfilling requirements #1 and #2 above. Dropbox internally uses a modified Subversion service, so architecturally, using an SCM backend for storage is possibly not a bad idea.
We've been playing around with the latest release and after following the setup instructions have been able to setup our own repositories on both Ubuntu and CentOS hosts.
SparkShare doesn't have an external API, but we trust that it's on the roadmap. We consider an API to be requirement to allow truly awesome integration in ways that not yet been considered.
We've definitely got great hopes for this project and wish the creators all the best.
Now we just need someone to come up with an open source Wuala stack...