Labels: javascript, noteToSelf

A quote from a blog I'm reading a lot more regularly now, Baldur Bjarnason's:

It's almost as if open source has become a system for transforming people's leisure time into free labour for corporations—eating up people's lives while driving them on with promises of future employment. (E.g. "GitHub is your resume".)

15 years ago, I had a long conversation with Bob Hughes (of Dust or Magic fame) about Free Software and open source. I was gushing about it

I talked about how it was going to change the world for the better, make software more egalitarian & democratic -- I was a bit of an idealist[.]

He then explained to me what was going to happen, how corporations and capitalism in general would twist the system to their benefit.

And then a follow-up here:

Instead of empowering the people and regular computer users, we've empowered VCs and tech billionaires.

OSS is still there for the rest of us to take advantage of, if we have the will and the skill, but it isn't doing much for your regular computer user.

I suppose that was Stallman's point about OSS versus Free Software in the first place.

I'm not sure what the angle Bjarnason's ascribing to RMS, but I bet I'll repeat it here accidentally.

Look, here's the problem with OSS... Well, here's the problem with indie-garage software coders (the toymakers) in general: As RMS says, software [sic] wants to be free. That's in large part why the App Store prices raced to the smallest possible (imagine if Apple had let you set any price! How many 12¢ apps would there be?). The marginal cost of distributing software, once written, quickly approaches nil.

What's neat is what you can do with software. If you make software that enables people in real time to do something interesting, you can sell that service. Software naturally enables. If your hours of github wrangling is worth 98¢ in actual cashola, but enables you (and others) to perform thousands of dollars of services, well, yes, github is your resume.

That is, if you chose to write server-side code, you've already boxed yourself into a use that'll never be customer facing. The flip side is -- your faceless, nearly designless software is barely worth anything on its own. There are so many replacements for what you've done. If you charge so much as 99¢, folks will go elsewhere. It stinks, but it's the hard truth. Sellable software requires design, serious design. Otherwise you'll never hit that group of end-users willing to give you real cash (the "market").

So it's better to give your services-focused software (your jQuery plugins and SQL profilers) away for free. At least then the barrier to entry of licensing and price is gone, and you have what's at worst an even playing field with your like-minded competitors. You probably still won't build the next Bootstrap, but now you at least have a shot. Hard truth time? Even those folks that try to eek a living out of customer-facing apps, and who are good at it, have a really hard time making ends meet.

And there's nothing wrong with writing code for a job. Server-side programming pays well. You will love your salary for doing brainteasers.

But you're not overtly using open source to be political in this case. You're following the market's natural direction. That is, these "resume" projects you're making are likely the easiest worthless projects (insert a smilie and remember that my assertion is that all software wants to be free and is, eventually, essentially worthless) you could make. And, again, good for you. Most people never share excellent worthless work. ;^)

Free Software's alternative

If Bjarnason's point is that non-GPL licenses are too lenient, I've agreed for years. You have to use a protective license if you want to create a privileged space that competes with capitalism. You must use capitalism to create this Free haven. The most brilliant, Deluezo-Guattarian move GNU ever made was to copyleft software. Use copyright to fight copyright. Use capitalism to fight capitalism. Inhabit, reassemble, and redirect. Don't fight head-on.

And it's the lack of inhabitation that's killing the dream of OSS (and GNU) idealists. Where are OSS' best wins on the client? LibreOffice, which is still a big win. Firefox, less important now that there's mobile, as Bjarnason points out. Even The Gimp or Audacity were good apps.

But none of these are best in class designs. Where is the better mail client, the better word processor, the better personal finance software? Where is the better desktop OS? Where is my hoverboard?

Cutting closer to the bone, how much Free software do you use "at home"? How about that phone in your pocket? Is it Free software? Look man, it's not. You're happy to use OSS at work, but you're not using it at home. How do you expect work software to make your home life better? How is Free software going to improve your life if you don't use it?

Better yet, WHY AREN'T MORE OF YOU CONTRIBUTING TO REPLICANT, the truly Free Android fork? In other words...

Why aren't we putting our time into game-changing software?

If you want to create that idealistic society that Free software enables, you have to work on projects that society cares about. As long as Free software remains derivative, it's going to be playing catch-up. And if Free clients are only as good as paid clients from ten years ago, platform-jumping (like the one from PC to mobile) will keep catching it by surprise.

Until we concentrate on the client -- that is, servicing the needs of people, dammit -- Free software will continue to gain a foothold only in those spaces where the software experience is completely fungible, like we see on servers today. It's not OSS' fault (I realize I'm conflating OSS and Free software too much) that we haven't created the ideal. It's ours.

(This is where, if I allowed myself more time, I'd start into suggestions about how to make this happen. Use Free software "at home" (and in your pocket). Learn the apps' foibles. Learn the languages used to create them, or figure out how best to recreate them. Find the pain points its users would have, and make the apps truly citizen-usable. And help folks figure out how to make Replicant work. There's like one dude plying away at the most important Free software project going, and that's simply not enough.)

Labels: app store, business, F/free, indie, OSS, rms

So M.G. Siegler goes against all sorts of conventional wisdom and says you don't want lots of users at launch. Whaaaaat?

The best-case scenario [after being featured on the App Store] is that those initial users taught you a lot and will make version 2.0 of the app that much better. The more likely scenario is that those users resulted in extremely noisy data which is not indicative of much beyond the fact that your app is both young and buggy.

And those initial users? They’re not going to give you another shot. Your time in the spotlight was largely wasted.

All of this leads to my seemingly counter-intuitive advice: avoid being featured by Apple in the App Store when you first launch your app at all costs.

That's directly contrary to Dan Counsell's recent advice (see here for one), and also against common sense. I understand his point: If what you release is crap, and lots of users' first impression of you is crap, you could end up with a stinky reputation that follows you forever.

I'd like to see three companies that have suffered such a horrible fate as to be undone by Apple featuring them on the App Store.

Look, if Siegler is seeing App Store featuring as something's that's killing businesses, I've got three pieces of advice.

1. Stop marketing and releasing products whose version 1s aren't any good.
2. Stop hiring managers that can't build teams capable of releasing good software (or who can't push back against/convince the CEO & board effectively enough).
3. Realize that maybe you're not so good at picking good freemium app companies.*

I think it's that easy. If free exposure is bad, your software's horrible. Learn to QA, and stop rushing to market, you wacky, initials-only venture capitalist. ;^)

* Honestly, the only way he could be getting so many users time after time that hit support so hard that it's killing businesses [to the point he doesn't want to be featured] is if they're free to download apps. Honestly, it's the *only* way.

Labels: app store, business, indie

So Dan Counsell kicked the hornets' nest again regarding MAS upgrades.

I know there's always been abandoned software and there always will be. It just feels like there's more of it now than ever before. Why is this?

One of the main culprits is the lack of paid upgrades on the Mac App Store.

Whoa. Any time you blame Apple, take a step back^[1].

Aren't there ways to provide paid upgrades? I mean, really, is it that complicated to dream up a way to include paid upgrades using In-App Purchases (IAPs)?

I understand that the MAS doesn't have a simple mechanism for making app upgrades, and is pretty clearly trying to, at least implicitly, encourage you to make software that your user buys only once and receives free upgrades forever. I understand that this isn't sustainable for indie devs, but I also know we're smart enough to work around it.

The problem's solution

So let's say I was, I don't know, writing an email client that I release just before or during 2016, and it costs you $55. It turns email from timesink to a thoughtless extension of your mind, and you can't stop yourself from clicking Buy.

During 2016, I code like mad and add a host of new features. Heck, let's get crazy and say I rewrite the entire app (btw, never do that). Now I want to release EmailClient 2017 for $55 for new folks, but only $10 for you, my loyal customer.

Seems easy on its face, doesn't it? I keep EmailClient on the MAS. It now has an IAP called, "Super Groovy 2017 features" that runs you $10. But, get this, if you never had the app installed, you get these features for free! Wait, what? Wacky, huh?

Implementation

The "only" problem is implementation, and yep, it's a problem^[2]. But isn't that what we do? We solve coding problems.

How could we do it? Well, if you have an email client, you have all sorts of methods, the most straightforward probably being to save a hash to a sandboxed folder with some user-identifying info, some salt, and the date of first use. And any app could do this reasonably safely, even without a simple web service, making the unlock of new features difficult, though obviously not impossible, to crack.^[3].

Poof. We have upgrade pricing. Right? I mean, it's a little code smelly, but we have it.

EDIT: I guess there's one issue -- we'll have an IAP those users don't need to buy. That's a tough call; I haven't played around with IAP on the MAS yet. Any context there? Can you hide an IAP inside of the app? Or direct folks directly to the IAP? I think the only IAP I've done is a tip for Pedometer++, and it seems like he had links to each option, which is very much like the prereq IAP stacking I mention, below.

The absolute worst case here is that we have to ship two apps painfully grafted into one. I've heard horror stories (particularly from the Core Intuition folk, if my memory serves) of moving from long untouched libraries to the recent ones, keeping old versions of XCode and OS X laying around to do emergency patches, and other related issues. I'm not sure you could ship some of this obsolete stuff easily in an app that's targeting 10.11.

Which brings me to the other upshot of this plan...

Eventually you're going to give it away for free

Maybe not in 2017, but at some point, maybe three releases later, I'm going to give everyone what's in EmailClient 2017, and give it to them for free. That is, you don't want an IAP list that says, "EmailClient 2017 Features, $10 -- EmailClient 2018 Features $10 -- EmailClient 2019 Features $10". If they didn't upgrade in 2017 or 2018, sort of like the license crackers, are they really in your market? They paid once. Why not give them a two year-old set of features?

And there are going to be times when it doesn't make sense to keep bundling together Frankenstein with the original parts. Occasionally, you might need to update EmailClient Y-1 to keep the tech stack in line with this year's EmailClient Y, but now that releasing grafted upgrades is your actual strategy, you can code defensively so that you minimize code that goes obsolete next year. Sometimes it's not going to be worth the trouble to make Y-1 play nicely with Y, and you'll be stuck. Let's just hope that, for the most part, your code from last year doesn't go obsolete within 24 months in impossible to fix ways too often.^[4]

I'm not sure if you can "stack" IAPs^[2] -- that is, require that users have EmailClient IAP 2017 before they can see EmailClient IAP 2018. I'm guessing you can't create "prerequisite IAPs", or I would've heard of a game doing it somewhere. "Want 400 gems for $5? You can, but first you've gotta buy 100 for $10!" Or worse: "$20 to unlock 1000 gem packs for $1!"

But not having IAP prerequisites isn't that bad, is it? And if things ever get so gnarly that you don't want to give something away for free, well, you have other options.

• You can pretend you're right back where we started, which is the worst it gets, and decide to release a new "EmailClient 2019" SKU.
• You can get clever and ensure that the features from 2019 can be used independently of features in 2018 (throwing in the subset of '18 features required for '19), and let users buy either. Which is to say that...
• You can have an IAP list that looks like instructions to a Rube Goldberg machine.
• You can get even more clever and hold back some features unless both 2018 and 2019 IAPs have been purchased. (Make sure your remind your 2018 & '19-only folks that's the case!)

There are nearly limitless ways to approach this problem. And, again, that's what brings us to the keyboards each morning, right? Fun, clever solutions to real-world problems. I mean, heck, Overcast already figured out how to perform an end-run around trial apps. Why can't we do the same for paid upgrades?

Reviews

Which is not to say the MAS doesn't still stink for new releases. This ycombinator comment in particular pains me:

But on the Mac App Store it takes months for an average application (read: one that is not permanently featured by Apple) to acquire said 5 ratings.

So you think twice about pushing out an update to your app when the current average rating is 4 or 5 stars. Because once your average stars are gone, your app doesn't look very different from any other 0 rating app... and it's pure luck if the user likes your icon enough to click on it. (Which measurably impacts sales numbers).

I see this with my own software... I once made the mistake to update a well rated app and sales plummeted over the next few months until the app could re-acquire 5 ratings to show an average.

I can see that. I wonder what percentage of folks review what kinds of apps. I have no idea.

I guess this just gives more weight to the lesson I hear everywhere: You have to advertise outside of the MAS to sell MAS apps. The MAS is one and only one of your storefronts (was it Liscio who built up this metaphor? He's been everywhere (#70) recently). You send trucks full of software there, but you're still responsible for convincing people they want to buy. If you count on Wal-Mart's shelf placement to sell your goods, you're not doing enough to grow your business.

Which is not to say we shouldn't keep challenging Apple to make the stores better. Which was Counsell's point all along, I think.

(Btw, if this is the first time you've read my blog, there's a decent, just under 110%, chance you won't want to read everything, which is pretty heavy on "notes to self" style posts. You might prefer to watch just the indie tag instead.

Unless you're Sam Soffes, in which case, if you're not as laid back (in that good way) as you sound, you might take this post badly. But then you could destroy this site's beautiful design, basically unchanged since 2001, and make up for it pretty quickly.)

Yes, the parenthetical in the title is supposed to remind you of Loser.

^[1] I think it was Charles Perry's AltConf talk that had some number like 0.01% of surveyed iOS App Store authors considered their apps financial successes. If you ask me, that's a pretty good explanation for all the abandonware. That and the fact that as the store progresses, by definition there are going to be more abandoned apps. I'm guessing there are very few resurrections. So don't get too down on the app store yet! (Perry's slide is below. Go watch his talk, and then a few more from AltConf too!)

^[2] Now is as good as any to admit I'm a C# guy just starting to write for OS X. Yes, I'm using Xamarin in the hopes that makes going crossplatform much easier. That said, I've used Macs for years, and have even contributed to a few Mac sites and a [trivial] piece in the Mac Bible's 6th edition, but in many places here, I'm talking without platform-specific knowledge of what the implementation would require.

^[3] I've been told that a lock is designed to keep an honest [hu]man honest. I think that's fair. We're doing the same thing here, because, honestly, what percentage of crack-artists were going to pay for your app? It's not zero, but it's also not close to 100%.

^[4] If you find that your code is going obsolete every 18 months, you might need to reconsider your dev workflow. ;^)

Labels: app store, business, indie, long

Customize how Find in Files results are displayed in the Find Results Window - The Ultimate Visual Studio Tips and Tricks Blog - Site Home - MSDN Blogs: 

You can customize your Find in Files results to show what you want to see and how you want to see it.

Example: You don’t want to view the entire file path shown in the Find Results tool window.

1. Open up RegEdit
   
2. Go to HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\Find
   
3. Add a new string called Find result format with a value of $f$e($l,$c):$t\r\n

UPDATE 6 July 2018: This got a lot more complicated. From that answer (and, now, personal experience): You now have to load what’s essentially a compressed version of a registry key set that lives in %localappdata%\Microsoft\VisualStudio\15.0_[instanceid]{RootSuffix}\privateregistry.bin, mount privateregistry.bin in RegEdit, do the same string value hack as above, then dismount privateregistry.bin from RegEdit. Bizarre.

But it’s even more bizarre that this isn’t a “real”, supported setting in Visual Studio yet.

Labels: noteToSelf, visual studio

Labels: fail, windows