I just push my photos up to an SFTP on a home server, which also pushes it to an encrypted offsite backup.
This has the advantage of working equally well for code(git repositories and everything being just directories with files), photos, videos, audio samples/tracks... anything which we're used to representing as files on UNIX-y systems.
I really don't understand why we need to jettison the boatloads of wonderful work which has been done to support files on UNIX, in search of a frontend interface difference for people(yes, many people) who don't understand files.
Not sure I understand completely. But I'm taking a stab...
For something like photos the interface is a very big problem. The UNIX file system, for example, doesn't help to visually organize tens of thousands of files (photos). There has to be a layer on top of that.
FYI, OpenPhoto supports a variety of "file systems" including the local file system or anything which can be mounted.
Whilst I agree with you in theory, and on the principle that probably 90% of POST, PUT or other various schemes to upload data could probably be better solved (and more securely) by a simple setup of rsync+SSH, there is the issue of end user interface. I don't want to have to browse through an Apache file listing of thousands of files named similarly to "2013-01-02_09:33.jpeg". I want thumbnails, and possibly other context (location, tags, etc). I also don't necessarily want to upload every single photo I take.
The macro problem with most photo library software is that it's trying to do far too many things and ends up doing none particularly well. A photo library software suite generally enables:
1. Photo storage,
2. Light photo editing (either of metadata or image data or both),
3. Photo viewing (including basic slideshow functions, etc.),
4. Photo organization (creation of albums, tagging people, and so on),
5. Photo sharing ("post this album to Facebook", etc.)
The problem is that no two of these tasks have a particularly logical relationship to one another. And as to most of them, there are better ways to do it.
As you note, we have put _enormous_ effort as a society into developing a very particular way to store blobs of data: the filesystem. It is a stable way. It is a well documented way. It is a way that has lots of tools that are also stable and well documented and mature. And best of all, it's really, really easy to back up. You can make copies of data on the filesystem in a trivial fashion. Back it up to an external drive! Back it up to a remote server, either owned by you or someone else! Encrypt the backups! Don't! It's easy. The same is true of photo editing, photo viewing, and many other things.
The one problem that photo libraries really solve is organization. It's nice to be able to make albums. It's nice to see all the photos taken around a similar time, or at a particular place, or with certain people in them. In fact, it's what makes huge collections workable. So I'm not knocking that. But what I am proposing is that there's got to be a way to disaggregate that singularly useful function from the mess of other things that photo library software doesn't need to do.
Note also that photos ought to be uncommonly easy to write organizational software for, because so many of them have built-in, well-documented metadata. Take a picture with your iPhone sometime and then dump the full EXIF info. There's a lot in there, way more than most people realize. And yet it's common to begin building photo library software by recreating all of that same information inside a proprietary and undocumented database. EXIF data includes a place for a description field---why doesn't photo library software _write to that?_ And files can have titles (or 'file names,' as they're called in the business)---why would you recreate, in some hidden-away SQLite database or something, the "title" attribute?
This has the advantage of working equally well for code(git repositories and everything being just directories with files), photos, videos, audio samples/tracks... anything which we're used to representing as files on UNIX-y systems.
I really don't understand why we need to jettison the boatloads of wonderful work which has been done to support files on UNIX, in search of a frontend interface difference for people(yes, many people) who don't understand files.