So much for that. Again. A while ago and in quite a verbose way I announced my move to KDE 4.x, specifically in the Kubuntu 13.04 distribution which I adopted in early alpha, as most of the time. Finally. After fancying with this particular desktop environment for quite a while. Well guess I’ll better keep quiet about things like that by now, sitting in front of an XFCE machine again as I write this, not ending up with a desktop that is “lightweight” or “un-bloated” but, well, with a desktop that seems to just have a better balance between features and usability, at the moment. Not sure. Some more thoughts on that to follow, read on…
Though I mostly use (server-sided) Java technology in my day-to-day work, I am then and now intrigued by Python as a straightforward, accessible scripting language which is easy to learn, easy to teach and immensely powerful in many situations. However, there are situations in which I just wished to have frameworks from the Java world available in Python… SOAP, to start with. Fortunately, Jython has been around for quite a while now, being a (re-)implementation of Python on top of the Java virtual machine, allowing for doing just that. And as we’re already using this in our internal development for certain purposes (Jython scripts to extend existing Java applications), I finally wanted to see how things work the other way ’round (using Java modules to enhance Python apps running in Jython). Here we go…
By now it should be known we’re notorious users of SAP MaxDB in a “non-SAP environment”, and, for that matter, we have done rather well throughout the last seven years. By now, we gained quite some experience running, administering, working with that RDBMS in our environment, and we manage to get our production work done on top of it without thinking about it all too much which seems a good thing. However, there are several nuissances about that platform, both talking about political SAP product and licensing decisions and about overall technical issues, lack of support for most of the neat tools, toys and frameworks included.
Maybe we could have seen that coming. In April 2012, some of us eventually enjoyed finally seeing the release of the Instagram app for Android devices. Up to then, Instagram was only available to users of iOS devices, leaving everyone else just then and now stumbling across images cross-posted to other social networks, not few wanting to be in there themselves, for whichever reason. Well, actually, despite I welcomed that app in a modestly sceptical way, I have to admit that by now, in there, I have posted more pictures than I posted to my Flickr account in almost eight years of being in there.
It’s simply a different way of imaging. Faster than anything I did before. I am not getting tired linking to this William Gibson interview, dating back to 1994 (a time when I still had no idea what “internet” actually was about).
“My favorite piece of technology is the Walkman. It forever changed the way we perceive music. The Walkman has given us the opportunity to listen to whatever kind of music we wanted wherever we wanted.”
To me, cell phone cameras are a technical achievement just like that. They have changed the way we perceive photography. They’re small, easy to operate, always there where we are. “Your camera doesn’t matter.” Period. “The best camera is the one that is with you”. Having these cameras connected to the internet goes one step further by allowing to even share moments snapped in a hurry to a worldwide audience, and services like Instagram just drive these ideas forth by providing tools, infrastructure, community to actually make this working, make it worthwhile, share these moments with dozens of friends and potentially tens of thousands of like-minded folks all over. And even better: Assuming you already paid for a camera-enabled phone and a data plan (you do have one when running around with a smartphone, haven’t you?), there’s no additional costs to that. No effort maintaining a custom web site for storing images, no clumsy upload or submit-via-e-mail – just upload through a slim, well-styled app (to be downloaded for free in the app store of your choice), and you’re done. Completely free.
Limitations and business models
Really free? Well, yes, at least at first look. Everything seems to be free by now. Facebook, Twitter, Tumblr, Instagram – no matter which of these social networks you look at, they’re free, they claim to remain free. But how? I have been running this web site ever since late 2002, and, same ever since these days I have been paying my web hoster to, well, do just as a web hoster has to do – provide me with web storage, bandwidth, e-mail connectivity, basic administration of my runtime and basic support. It’s not free. Taking it to a commercial level, this gets even more interesting. I’m not working for either Instagram or Facebook but rather for a German SME offering structured hosting and access to server-sided document archives as part of its overall service. In running this infrastructure, we always have seen that this infrastructure is expensive. Storage is expensive. Fast storage is more expensive. Fast storage that is available at least, say, 12×5 each week is very expensive. Fast and reliable storage, available 24×7, ready and scaled to server tens of thousands of concurrent users around the globe is most likely to be by magnitudes more expensive. Exactly the same goes for bandwidth. Or support engineers that keep this system running 24×7, who are around, ready to fix things and get the mess up again even on Sundays, during Christmas or on New Years Eve while everyone is trying to post her or his “Happy New Year” shots. Not to mention software engineers to build the server-sided custom infrastructure, to create, design, roll out the mobile apps to the end users, to fix issues and maintain this in a way that keeps end users happy. Sure, some of the infrastructure aspects in this can eventually be optimized if your business allows utilizing cloud services as provided by Amazon or Google, but ultimately, even if you do so, you’ll still be charged. So in the end, are services like Instagram, Facebook or Twitter aren’t free to the end user because they are inexpensive to the provider? I don’t work for either of these, as said, but I thoroughly doubt so. It’s more likely that, assuming the services don’t charge the end user for using it, they will find some other way to at least cover any running costs, and to make some profit out of it in order to stay in business. That’s perfectly fine, but it might get difficult at times.
So to happen in case of Instagram: Just a few days after installing the Android app, I see a vast load of black pictures appearing in my stream. Figuring out why was just a matter of moments: News is that Facebook acquired Instagram for an enormous chunk of money. Not necessarily bad, merely just logical from some point of view as both companies possibly might be sharing some “synergies” in common concerns such as infrastructure, developing and supporting mobile apps, and eventually making users in both services interact with each other in a better way. Then again, by now it is pretty likely that Instagram will even more than before be required not just to run on covering its costs but to actually be profitable in order to justify the price that has been paid for that company.
But how? Facebook and Twitter, at the very least, are left with things such as user-specific advertisements, “premium pages” for businesses and the like as actual or possible models of generating revenue. But Instagram? The app is free of charge. Using the service is free of charge. There aren’t ads in neither app itself nor the photo stream in the app, and web profiles haven’t been around, either, since a few weeks ago. Ad-free, too. So how is a company like Instagram supposed to make money? Eventually, for that they will somehow have to utilize the only real asset they’ve got – their user data, especially of course images posted by their users.
An obvious idea, of course. Subsequently, in December 2012, web’s been flooded with articles announcing a change of Instagram TOS and what these changes would mean to end users, all along with load of statements all over news sites and blogs bashing Instagram right for that and tutorials outlining how to download all of your Instagram pictures before deleting the account in there. Suddenly there are services like flickstagram helping you to move your Instagram images (and, at best, also metadata associated with it, such as comments and “likes”) to other platforms like Flickr.
Instagram seems to step back a few days later, and all along there as well are other post out there clarifying that one of the worst claims (“Instagram can sell users images to anyone without your consent or even mentioning you”) just, well, hold partially true, and that the revised Instagram TOS basically aren’t too much different from their initial ones, just written in a shorter, more concise wording. In the meantime, some reports even believe a large amount of users to be dropping out of Instagram just because of that. Personally I don’t really believe in that very much, but I do see quite a bunch of new users appearing on Flickr, and I also experienced many of contacts of mine in there obviously copying in their Instagram stuff. For whatever it’s worth.
So what about it? Sh*t storm? Much ado about nothing? In the end, it doesn’t really matter, I guess. Maybe
the genie is out of the bottle now something actually obvious has become a bit more publicity by now: (Companies like) Instagram, too, can’t live just off being popular but need some way to earn money, the set of options at hand to do so is limited – mainly to making “creative” use of the content people posted there. No matter how you put it – using such services, no matter how fun or straightforward it may be – you’re pretty much giving up control of what happens to the data you put there. You need to trust your provider in order to do so. Maybe, in case of Instagram, this is the worst outcome of the whole TOS mess-up: People losing trust in what Instagram does and how they do it. Some will flee because of that, most possibly won’t care and still remain there. Some may see that having the provider make use of “their” content in some way is the trade-off to accept when using the service completely free-of-charge. Some will eventually choose a middle ground, will be more careful about what they put there by, at the same time, considering other places where they are more capable to control their content.
So, what to do? Personally, I’m more likely to follow the latter approach. I’ll eventually remain on Instagram, as, ultimately, the kind of stuff posted there just reflects a certain viewpoint of mine, a collection of “quick shots” taken on my way through the days. Asides that, however, I’ll keep a close eye on what’s happening on Instagram, and I will also revive my Flickr Pro account. Compared to others, Flickr falls a bit behind in terms of features and mobile apps (especially their Android version leaves a loads of things to be desired), but I have a bunch of kind contacts in there, and I overally want to support the idea of such a service actually being used by customers who pay for a service that is in some way valuable to them. And, asides that, I will merrily follow what ktinka used to write an article worth reading on that, a while ago, keeping my very own blog for all the things I don’t want to see in either Instagram or Flickr or elsewhere but just here. And, given there’s quite a good Android app for WordPress, maybe even posting images on the go sooner or later will work out this way, despite lackiing all the feedback and fun and links to be found in Instagram and friends.
Sometimes, maybe this isn’t really needed.
Putting action where the mouth is, I guess: At the very least with its 4.x release, I then and now considered the K Desktop Environment (KDE) to be the most technically advanced at least amongst the Open Source / Software Libre desktop systems. Took me a while to actually adopt it for day-to-day use. However, that time is now I guess.
Deleted code doesn’t contain bugs, they say. I always felt kind of unsafe with the idea of actually and straightforward removing code while into refactoring smaller or larger parts of the systems – after all, same as it doesn’t contain bugs, deleted code also doesn’t contain business logic anymore which might not be what you want at times. Yet, trying to clean up parts of (the Java / Java EE based) components in our system, I have to some degree changed my mind about that.