Building Ambisonia.com

I use a lot of open-source software. I’m constantly hopping on and off email lists for open-source software. I talk to a lot of open-source software developers. I’ve been the creator of a couple of (failed) open-source software projects. And recently I attempted to organise a group of people to put together an open-source specification for modelling ambisonic data (it didn’t really work).

Over the years, I’ve noticed a few things.

1. Head strong visionary at the helm. I reckon that all successful open-source projects have had a head-strong visionary at the helm. At least until the project is established.
   1. You can see the lack of that in the FLAC lists, where discussions about a potential ambisonic format fizzle in circular group arguments.
   2. You can see it in the Shoes list, since _why has dropped off the radar, there is a lack of coherence where the direction of the development might just end up following whoever seems to shout the most (or post the most).
   3. You can see it with WavPack, where the author David Bryan responds clearly, succintly and with forward-motion in mind when new features are discussed.
   4. You can see it in the ambisonics Google list that I set up to try and establish an open-source ambisonic format. It didn’t work because I was trying to be too-democratic… there’s simply too many opinions. I should have intercepted and led much more strongly (I kinda did that but very late).
2. Ignored bug means death. An un-repaired bug can kill an open-source project. An ignored bug signals abandonment.
   1. There was a AWS::S3 windows bug that quite a few people were complaining about on the lists. The authors just ignored them (probably because they were developing on OSX and deploying to Unix). It really strongly put me off using not just that project but any other projects by those authors.
   2. I’ve been astounded at the quickness of support (bug squashing) on some open-source projects. It gives you the confidence to use and depend on those projects more. I’ve always been impressed by the response on the SND list (computer music software). The SuperCollider list is good too.
3. Cordiality and respect. Many developers develop a diva syndrome. I guess when you write software from the ground up, you get to know that code better than anyone else. Many developers end up interpreting this as meaning that they are more intelligent than their users (or other developers)… and they develop a ‘diva’ syndrome.
   1. I’ve seen this recently on the Perian list, where the authors respond with terse unhelpful comments. I unsubscribe immediately. Actually, I’ve seen this on almost all lists (not always from the core developers though).
   2. When open-source developers show respect for their users, I think it has a big impact. _why was always very good like this on the Shoe list, which is why I think he could have a huge impact on software (if he could just focus (perhaps?)).

One of the attitudes that irritates me the most is the “this is open-source software so if you have a problem with it then fix it yourself” attitude.

There’s nothing more annoying than when you land on a webpage and the authors are saying “use our software! its great, it does this this and this, and its free!”. Then you encounter an issue, you post on their list and they respond with that “sorry, its your problem” angle. Its schizophrenic, and immature. If you are putting a product out there, take responsibility for it.

Trying to think like a user, when I’m fully aware of the $ figures behind the scenes, has to be the most difficult thing I’ve done so far on SoundOfSpace.com. But as a result of doing that I’ve just changed the account model to one that I would much prefer as a user… its just more risky $ wise. Let me explain.

I do some quick calculations, and determine that I need to charge X amount for X features.

Then I cast my head into a “user” and ask myself … “would I use this service if I was charged that much?”. If the answer is ‘no’ then I have to ask myself “well, what would I pay for?”.

This is particularly difficult for me, because I’m cheap. I just dont like paying for Internet services. So whenever I ask myself if I would pay for a certain service …. my answer is often ‘no’. There are actually very few internet services I pay for. I think there’s 3.

As a user (with a free account), having only my last 3 uploads visible just doesn’t work for me. Actually, the whole concept of paying for ‘visibility’ doesn’t work. Why bother to upload stuff if it will just drop off the radar once I get to my 4th upload. Its a bit of a lock-in … I feel wedged. Feels like I’m being conned into being up-sold a premium account just to avoid the annoying things in the free account.

Doesn’t work. So I’ve changed it.

Now, when you create a new account you are allowed 3 uploads in the first month. Then you are allowed 1 upload every month. Nothing will ever drop off the site. If you have fulfilled your quota for that month … dont worry, just wait and you will be able to upload more.

This is really just a way to slow down free uploads (which costs the site money) … but without introducing negative experiences (like when one of your tracks drops off the site).

It is also a way to cater for 90% of the site’s users (who will really only ever need to upload once a month) … without having any degraded performance. It also removes the uncomfortable up-sell to premium services.

I think the up-sell to premium services must be a pull, not a push. In other words, the users should feel excited to go to premium services, rather than pushed there to avoid some negative experience with the free accounts.

I wont talk about the dollars … but … this strategy is more risky, because if no one upgrades to premium services then my costs will slowly go up and up.

Once scaling is complete, its going to be all about micropayments.

The one big last final cathartic step in the ambisonia adventure is going to be enabling people to tip the content producers. Yep. That’s been ambisonia’s long stated aim … to create a micro-economy around ambisonics.

photo by danielbroche

This is both a technology challenge, and a user interface challenge. No one is going to tip anyone if tipping is not:

1. extremely easy
2. cheap
3. satisfying

But the user interface issue is secondary, for now, to the technology.

Amazon FPS is the perfect solution, but you need to have a US credit card and have a US address. I dont have either.

Paypal is apparently coming out with a micropayment API very similar to Amazons, but there’s no sign of it yet.

And now there’s rumours of Google also developing a micropayment solution based on Google Checkout. Darn. Google Checkout is also only for US based merchants.

So right now its not looking too good. That is unless I move to the US.

Ok. Patience. Lets see how things pan out over the coming months.

soundofspace.com is now 95% ready.

statistics

I’ve got statistics running now. They are good. They enable you to get a good understanding of which pieces are getting hits, and when. There’s more info that I am collecting that I can present as well, but exactly which info is useful can be determined later, as the site evolves.

The primary issue now is helping people get the 5.1 system hooked up to their computer. The AV route (via digital pass through) is proving to be not so good. I’ve emailed the Perian people (who make the quicktime plugin that allows digital pass through on OSX) and they say that their plugin waits for the whole file to be downloaded before playing it…. but they say it doesn’t have to be that way because ac3 can be streamed.

Tests work on Safari, but not on Firefox (OSX). So getting ac3 to your digital receiver really isn’t there yet.

Any C programmers with a bit of time on their hands? … the Perian people say its just a matter of adding streaming support to their code … then streaming AC3 to the AV receiver would work on OSX (but will it work on OSX?).

As for windows, well, I havn’t had the time to do much testing yet. This is important because most users are on windows. If you have a 5.1 soundcard, then you’ll be right. But if you want to do direct to AV receiver on windows, then I’m really not sure how to go about that. Any suggestions?

So that’s what missing right now … documentation. Documentation then ramp up traffic

Next step after documentation:  scaling.

I havn’t used *any* of Rails’ caching tricks. But I will soon. The audio files are being served off Amazon, so they dont take up any server bandwidth at all. So scaling should be relatively straight forward.

Weird how project management works out.

There’s the 80/20 rule… you know … 80% of the work takes 20% of the time and the last 20% of work takes 80% of the time. I’ve never seen a project that doesn’t follow this pattern.

But I’ve discovered a new pattern too. The last 2% of the work seems to just burst out of thin air onto the table, very quickly. There’s a kind of “I can see the finish line” enthusiasm that energises and ups the results.

Spring Snow Burst from Sister72

Check it out: www.soundofspace.com. Its not ready for public release yet. Still have the real-time stats graphing to complete. That wont be too difficult, but the tipping system will take a few months yet (because of e-commerce challenges). But hey … its real. Its not just talk anymore. What a relief.

www.soundofspace.com has all the features that were lacking in ambisonia.com. Most importantly … it has streaming 5.1 direct from the webpage. That’s revolutionary. It just makes it so easy to listen to surround now.

You can also mix up tracks together. I’ve done the navigation largely in AJAX … so you can navigate around and look for other things to play _whilst_ you’re listening to something.

Uploads are done directly in the web browser … no application is required to download.

Transcodes are done instantly … no waiting for little old me to log in, download tracks, transcode them, and re-load them again (hmmmm, that was never going to work).

The server is hosted in the US (Amazon EC2), so no more slow speeds from my home server in Australia.

The streaming audio downloads are also hosted in the US, from a highly performative and scalable service provider (Amazon S3), so good performance can always be expected.

The server has been implemented with a caching system, so page delivery should be fast.

The site has been implemented, from scratch, with the best web-application-platform I could find. Rails. Love Rails.

All plays and downloads are registered in real-time, so for the premium account subscribers, real-time statistics are right there (or will be very soon).

And there’s an e-commerce system for subscriptions to cover the expensive audio streaming costs.

Now all I need to do is implement the tipping system and WHAMO … I will have fulfilled my long-stated goal of creating a micro-economy around ambisonics. This part will take a while. I have to work out how to minimise credit card transaction commissions … and to forge the web site’s useage patterns to optimise encouragement for people to tip. That’s going to be the big big final challenge.

What’s the impact of making a bad technology choice?

I’ve made the wrong technology choice several times now. What I’ve learnt is never commit to a technology. Stay loose, dont be afraid to move to an entirely new technology. Implement everything as loosely connected parts.

HTTP based APIs are good, shell scripts are good etc… choose an architecture where you can easily and quickly replace parts with entirely new technologies.

You know when you’ve made a bad technology choice when your battling, not building. You know you’ve made a bad technology choice when you keep postponing implementing something really important because you know it will be a shit fight difficult.

A bad technology choice is a ball and chain. A good technology choice empowers. The cost of switching from one to the other will not matter when you’re sprinting away on the other side of the fence.

I used to tear my hair out trying to get Plone to do what I wanted. Arghh. I used to think,” just stay with it, you’ve come this far, it will take too much to swap from scratch now.” Wrong wrong wrong. Should have just moved on.

A bad technology choice never goes away.

One of the reasons I have been hesitant to move away from Ruby Shoes is because I’ve put so much effort into the Shoes uploader. Wrong wrong wrong. I should have moved on much much earlier.

I’ve finally found a workable solution to the cross platform uploader. It took me about 3 days to code it up. 3 days! … I’ve spent longer than that just trying to get Net::http working in Shoes.

The block to moving, I guess, is fear of the unknown. For some reason it seems much easier to stay with a bad solution that try to explore for newer solutions. Better the devil you know. Hah. That’s so wrong.

Its an unsolved challenge … the cross-platform GUI toolkit. It just doesn’t exist in the right form. There’s lots of contenders, but all fall short in some critical way.

It should be simple, all I want to do is create a little cross-platform app that allows my users to upload a large file to a website and report on the upload progress.

My requirements are simple:

1. I dont want to have to compile code or execute code or do packageing tasks on all 3 major OS’es (i.e. Qt, GTK, Tk, Fox, wxWdigets etc.). Just give me the toolkit, let me press the button that spits out DMG, EXE and .sh (or whatever linux uses).
2. I dont want to be a glaring advertisement for an app development platform …. that’s right, I dont want someone else’s branding and icons all over my app. (AIR, Shoes, etc.) It will just confuse and concern my users.
3. I dont want to depend on something that might disappear. Appcelerator does its packaging in the cloud … no!
4. I dont want to write C or C++ … I’ve got better things to do.
5. I dont want to be drowned in some managed marketting muffle. That’s you AIR! … stop selling and just show me how it works.
6. I dont want my user to have to download a platform before installing my app! (AIR, Swing etc.) And please dont try to sell me that I can bundle the platform for a fee.
7. I dont want to give my users an app that will then download the *real* app. How do I convince my users that I’m not just installing porn on their harddrive? I want to distribute an app, not an installer!
8. I dont want to use some huuuuge application platform that would theoretically allow me to build a 3D rendering application with bells and whistles and blablabla (Mozilla, Qt, etc.). I just want an uploader.
9. Dont even mention the word RIA … its just a buzzword used by people looking to invest money so that they can make money, for money’s sake and maybe a fast car and lots of big houses with lots of cash and money money money, note to self:must cash in on RIA and other buzzword technologies.
10. Just because a toolkit can do a ‘hello world’ twitter client doesn’t mean anything. Twitter clients just do extremely simple HTTP gets and posts. Try doing a multi-part form upload with large files and reporting on the upload progress. Someone should invent a ‘hello universe’ concept that allows people to test the maturity of new software products.

Lastly … and mostly … I dont want to use some toolkit that’s developed open source by one single person, as a hobby, between other hobbies.

Have a look at how many projects _why has on the boil. What’s this Potion thing he is spending all his time on? … its a whole new language! … oh shit. Its not looking good for Shoes. I’ve wasted so much time on half-baked Shoes.

Where to from here? Subscription accounts are practically completed … I’m that close to launching the site in fully functional commercial mode … I just need to find some decent little toolkit that allows my users to get the content on the site easily and from any OS. arghh.

Amazon FPS suits ambisonia.com’s commercial needs very well in more than one way.

Firtsly, not only does FPS have solid support for micro-payments … but it is even capable of viably doing transactions of less than 5c! That’s quite revolutionary in online payment systems.

A payment of 4c, for example, will incur a commission of 20% of the transaction amount, with a minimum fee of $0.0025 …. which comes to 1.05c.

Ok so that’s a little bit more than a quarter of the payment. But compare that to PayPal, which takes around 2.9% + $0.30 USD …. which means that a 4c payment would cost 30.116c.

Secondly, Amazon FPS is what is known as a marketplace solution. That essentially means that I could delegate payments (of tips) directly to the ambisonic content uploaders.

Currently, the aim is to hold onto any tip payments and then once they reach a sum large enough to be able to absorb transaction fees, pass then on to the uploaders.

With Amazon FPS, ambisonia.com could instantaneously take a small commission, then pass the bulk of the sum onto the uploader. The uploaders would then have a kind of real-time dashboard of how many tips they are pulling, and be able to withdraw those tips immediately.

And it woudln’t be that hard to code up (from where I am now).

I’ve been quiet, but things are moving.

I’ve got almost fully-functional e-commerce functionality built into the new site. I’ve got secure SSL pages working, I’ve fully debugged every scenario I can think of (WRT credit card transactions). I’ve got real-time stats going for the premium users. I dont have tips going yet … but that isn’t far from the infrastructure that’s in place.

Now I’ve hit a hurdle. Its a big one. Its simply not possible to do small-sum credit card transactions to international customers from Australia. I cant charge international customers 5USD for a service/product, the payment infrastructure just wont cope with that. Here’s the run down:

I’m in Australia. I dont want to charge in Australian dollars, its not ‘international’ … and people will get weird sums on their credit card statements.

If I charge in USD, the banks will use the Swift interbank system for translating the USD amount into Australian dollars. It costs anything from $10 to $16 *per transaction* to convert from USD to AUD! So a transaction of $5 will cost me $10-$16!

Solution 1: charge large sums … doesn’t work for my business model.

Solution 2: get a multi-currency account based in Australia. The only Australian bank that offers this service is the NAB. By having a USD account in Australia, I can avoid that Swift interbank charge. But now there’s a new problem … multi-currency accounts cost $1200 to set up, have a substantial monthly fee and depending on the maturity of your business, they require a floating account balance of 5-20k USD! That’s out of my league.

Solution 3: use PayPal’s Payflow Pro gateway. But it costs $150/month … and you still need a merchant services account (usually around $50/month).

Solution 4: get a USD bank account in the US. I dont know if this is possible, let alone legitimate.

Solution 5: take my business out of Australia.

I keep thinking that surely this is wrong, there’s gotta be a solution for this scenario. Maybe I havn’t researched enough … and then I found this discussion on a Google group, which confirmed my fears… that there’s simply no easy solution for selling smallish sums to international customers.

I’m still researching. I’ve found that Amazon FPS is one of the only payment gateway solutions that caters for micro-payments. Unfortunately, they only sell their services to merchants with a USD credit card and a US address.

Most credit card gateways take a percentage (like 3%) plus a transaction fee (like 30c). So if you want to sell something for $1 .. you lose 33c (one third). But Amazon FPS has special pricing for transactions under $10 … the commission is 5%, and the transaction fee is 0.05. So if you sell something for $1 … you only lose 10c, which is reasonable and viable. But I dont live in the US

Its going to take some effort and thinking outside the box to jump this hurdle …

An interesting article about giving away music … suggesting that the higher the quality and length of the sample, the more likelyhood people will want to pay for it.