Tuesday, April 28, 2015

Software Subscription fee? Or just Vapor-ware?

From a sound engineer I know:
This is the new Pro Tools, it's now a subscription, for a mere $200 a year to stay current. However, if you peruse the list of new features, they all say "coming soon". You pay a subscription fee today for features that aren't even live yet. It's like I'm paying for an open beta of PT12 
I feel this is becoming a more prevalent and systemic problem in software development. Am I wrong? What is going on here?
Is it right to ask a fee in advance for features to be developed in the future? Is this a sustainable business model? Or will customers eventually rebel and switch to another product with better licensing terms and conditions?

Further, this clearly isn't a "purchase" in any traditional sense. Software has always lived in a weird zone where you don't really purchase the software in any sense, you purchase a right to use the software under limited terms and conditions spelled out in an end-user agreement that you probably didn't read. Since you didn't actually purchase it, you can't reverse engineer it or modify it.

It's my understanding that Avid's Pro Tools is the gold standard in the sound engineering industry. It seems unlikely that open source startups will catch up to the power of Avid's product offerings and undercut their pricing.

But -- of course -- who could imagine that MySQL or PostgreSQL would erode significant marketshare from Oracle or IBM?  Indeed, how much marketshare has been consumed by SQLite?

Software prices appear to have plummeted over the decades. In some cases, the drop is real and the root cause seems to be open source tools to build software. In other cases, the drop is a spreading of costs via subscription services like this one.

What if Avid doesn't deliver on their promises? You've forked over $200 and didn't get the promised new features. What now?

Tuesday, April 14, 2015

Java vs Python

Seems silly at first.


It's mostly true. It's also incomplete.

For example, "no tuples in Java" ignores http://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/tuple/package-summary.html.

It seems like the only interesting takeaway from the infographic is that Java syntax is wordy.

One hesitates at a detail-by-detail comparison. Does it help to match the 20 or so statements in Python against equivalents in Java?  Does it help to match the byzantine complexity of Java public/protected/private against something that doesn't exist in Python? Does it even make sense to try and compare the complexity of Java annotations with anything? What about Python meta-programming? The fact that we can easily overload Python operators?

Perhaps it's only because I'm an expert in both languages that I hesitate to try point-by-point comparison.

Tuesday, April 7, 2015

Going to PyCon 2015

In Montreal! How cool is that?

I'll be working for my current employer, also a sponsor, to locate Python talent.

I'll have a few copies of my books that I can give away.

Most importantly, the promotional code PYCON_LOTT gives 50% off my Packt titles and runs from April 7th to April 14th