mISV Release In 30 Days Or Bust Trying

Recently on the Business of Software Forums Patrick McKenzie of BingoCard Creator fame announced he was about to embark on his second mISV product and was planning on an early July release.  As it’s towards the end of May as I write this that’s as close to a “30 Day Develop and Release” window as you’re likely to get.

Patrick invited other mISV’s who were in around the same position to get together via our blogs and track what we’re up to over the period.  A very interesting sociological/business experiment for other ISV’s and one that also benefits the bloggers involved in terms of motivation and keeping on target during their development/release cycle.

As I’ve outlined in other blog entries here I’m in the process of building an mISV.  So I’ve decided to join this effort along with other bloggers.  I’m going to add a menu option at the top of this blog for a list of participants and their blogs and when ready with direct links to their products.

Now, in a sense I’m already underway.  As I’ve mentioned here my wife has joined me as a business partner and we have two kinds of applications.  The main product is the product development in “30 Days” that I’ll be concentrating on in posts here over the next few weeks.  The other products are mini applications written entirely for cash flow to assist in start-up.

These “mini” applications were released last week and are being marketed on eBay only at this time.  So far I’ve only added five to get a feel for things there and to acclimatize my wife into the world of software sales and the internet which is all very new to her.

Sales so far are just over $260.  Not to bad for a couple of simple applications for collectors of specific plant species in a week.  A lot of tweaking is needed on the auctions themselves and the main website is still not done (I’ve been absent pretty much online for a week due to a particularly nasty flu – it’s almost winter here in Australia and the bugs are on the move early).

These little app’s took a day to write the core code.  Each variation takes around 30 minutes to create now including building, setup compiler, unlock keys etc which are built using a build tool.  The apps include PKV serial numbers; I’m road testing this technique ready for the main application to be discussed below.  The PKV (Partial Key Verification) allows for over 2 and a half thousand key combinations for the purpose of breaking keygens all inside a 36 digit key.  Encryption of code at this stage is being handled by some older tools I own but I’ll be upgrading to something more modern (and DEP safe) soon.  I’m not at all concerned about cracks for these products, as I say, it’s road testing for the main application which I expect some pimply faced pirate to go after at some point.  I’ve also placed crack honey pots in there for the incurably lame script kiddies and judging by the weblogs for this blog the search for cracks and “tuts” is popular.

Once the website is up I’ll post some screenshots to these programs to give you an idea of UI and just how simple they are.

Now, the main product for us is much more complex.  It’s an audio application aimed at the semi-semi-pro market.  There are two competitors for it currently, one on Windows and one on Mac.  I’ll be targeting the Mac later and the initial release will be the Windows version.  Compiler is Delphi 2007 with an assortment of VCL widgets I’ve either built or purchased.  At this juncture I’m not ready to reveal the exact nature of the application (though the website has a Google food page already so it’s already in Google and other engines).  As this series of posts progresses closer to release I’ll reveal the nature of this software package.

Currently the development situation is this:

1. The audio engine has been written.  On Windows it heavily uses Direct-X, on the Mac it targets Core Audio and similar libraries. I have no timeframe set for the Mac version at this juncture.  Nix will not be targeted at this time.  I’ve toyed with the idea, but there are hardware complications and audio library complications I don’t want to lose time fussing with at this juncture.   I certainly have no interest in entertaining the “Software’s got to be free” FOS and GNU enthusiasts. 

2. The “project” file format has been written.  This is a file object that stores all the data for an audio ”project” for the applications end user.  It’s cross platform.  So a customer can design an audio “project” and move it to another machine and use it there (without losing any settings for the project including all used audio files) on either platform.  The settings control files inside, for a “project”, is handled via XML to achieve this.

3. The audio file format is an OGG variant that I’ve added some features to for “projects”.  Customer can access audio file formats from MO3, MP3, WAV and pretty much anything in between (most known and some lesser known formats) but the audio file is imported and converted by the application for storage. 

 I’ve chosen this path as the whole patent issue regarding audio file formats (particularly MP3) is to fluid, even when licensed fully as we will be.  This way if a certain patents compliance becomes untenable we can simply drop that audio file format and not break the program.  OGG of course is patent free.  Our Windows competitor can only handle 16 bit Riff Wav files.  We will be including support for 32 bit Wav’s in our product.

4. Put quite a lot of effort into streaming data in and out of the “project” file instead of dumping the data to a directory, which is what most audio programs do.  The biggest hurdle was system resources with audio files.  However we seem to overcome these and things work nicely even in 256 Meg of RAM (tested on a very old laptop I still have).  Basically the “project” file works like a virtual file system only it is compressed and encoded with encryption.  The encryption is only there to slow down any competitive efforts to import our “project” files.  Yes – I’m a mean bugger.    But if they approach me for licensing access I’d be reasonable about that.

5. OS support will be mainly XP and Vista extended to Windows 2000 with the latest service packs.  I will not be supporting Win 95/98/Millenium or NT4.  It creates too many problems with Direct-X versions, file systems etc and many of these systems won’t have the graphics or RAM required anyway.  Have not established at this point how much of my target market (this is pretty much a niche product) is affected by this decision. 

6. Program will feature an online “Store” available through the main interface via embedded IE control.  This basically will offer music and sound effects via our CDRoo website services.  These offerings will be licensed in such a way that they permit public performance which most commercial tracks available prohibit.  Content will be licensed direct – no middle men here – and controlled exclusively by us.  I already have some of the content available and am in the process of adding more.  A friend of mine suggested that the embeding of IE might preclude sales to people who have uninstalled the browser completely from their Windows installation.  Given how heavily “wired” IE is into Windows I’m prepared to accept this loss from those who so blythely hack their OS.  I’ve found no valid reason to do so (this is not a security issue as far as removing IE is concerned) so I’m not bothered by this.

7. For the UI on the Windows version I’ve borrowed heavily from both Windows and Mac.  It does feature gradient blue out of the box – but this will be configurable by the user should they wish a different colour scheme.  The colour scheme configuration is on the to-do list presently and not marked as a priority.  I’d be happy to go to release without this option initially.  The Mac version of course will be very much a Cocoa compliant look and feel application.

8. The ubiquitous treeview control handles “project” elements inside the UI and that’s planned for both platforms.  Full drag drop (which required a bit of tweaking as the references inside the “project” file need to be updated on drop) is implemented and other similar niceties people expect.  A standard listiview object handles playlists for the actual audio and these playlists are much more complex than what appears to the customer on the screen – handled via XML as well.  The complexity (hidden) of the playlist is what gives the application the ability to work as if scripted – without requiring the customer to actually learn or ever actually become involved in scripts.  Point and click is the order of the day here when it comes to achieving automation of a “project”.

9. The competition all use standard file open dialogs to import audio tracks.  We have included a file explorer into the main UI (which can be toggled open or closed) to facilitate drag drop into a “project” and in addition the customer has the option of indexing their audio library via a database which will make locating audio considerably faster than a file search (which will also be available).  It will feature a wizard to perform the addition of content to the database should they wish to use that.  Clearly some form of “broken link” detection will need to be available and of course it should auto-repair as appropriate or at least offer to do so.  On Windows the database is internally proprietary and the Mac will probably be SQLite.   I don’t like the speed or functionality of SQLite on Windows via the available Delphi API’s and components (free or commercial).  Also the proprietary format can store gigs more data than SQLite.  As the database is a local index of files it would be irrelevant to be concerned about cross-platform movement for the data so this is not an issue for the database.

10. It’s got to be FUN!  I’ve had enough in years gone by (corporate and as a small software vendor) writing serious applications for serious purposes.  This application has the requirement of being fun to use and fun to develop.  Sure – there are always headaches – but overall the feeling has got to be fun for my customers and I or there is simply no point.

11. Standard Pro Audio paradigms have been broken in this program on purpose.  Yep.  How many folks not in the audio field can really understand and manipulate a waveform?  My own experiments have shown that such things confuse and obfuscate their purposes (and downright terrify some) when presented to “average folk”.  So waveforms are out graphically speaking and all the complex handling will be done by the software internally, with the customer manipulating familiar widgets like track bars (in one case dual ended track bars allowing start and finish points to be set).   It will be possible to tweak and configure a plethora of audio “effects” but by default these options are tucked away (available though a button click for each option) with the customer presented with presets for each effect – again with an emphasis on making it fun and to encourage experimentation.  However they can be completely ignored and do not get in the way should the customer have no interest in them.

12. Just because I have a certification in Audio Engineering does not mean my customer should need to – or want to.  That point is posted above my desk on a piece of A4 paper in large felt marker ink.

13. Removable storage will be supported directly including copying to USB devices and of course burning to CD/DVD.  This is necessary to facilitate building “projects” at one location (say home) and taking it to another location possibly on another machine with the product installed.  In addition an audio CD burning option will be available to allow the customer to create a playable CD if they so wish to do so.

14. Licensing initially will be the Borland style “Like a Book” license where by a single user can install the software on multiple machines providing only one person accesses the software at a time.  This works best with the nature of the product which would reasonably be installed on say a main desktop machine and a laptop.  Multi-user licenses will be available.  We’ll trial this license for a while and if necessary tweak or change as needed.

15. Competitor differentiation is essentially through the variety of audio formats offered, the “project” nature of the entire process and the automation of the result.  UI wise even the first draft is more polished than existing competitors and the software runs 99% faster even with a “project” loaded at start-up in very basic tests of the UI done to date and resource usage is lower.  It works out of the box and does it in under 5 megs – unlike the Windows competitor we have who is using .Net. Later in other posts I’ll provide hints for comparison for those who are interested – but I will not name or link to competing products, so you’ll have to Google for yourself. 

OK.  That’s probably a lot more than I intended to write here at this juncture and if you made it this far through then you either have nothing to do or are interested in the “Can we do this stuff in 30 Days or Bust” angle. ;-)  So I’ll leave you now to pursue pressing matters in your own life with the caveat that I’d take it extremely poorly if anybody was to decide to emulate directly any of the people involved in this “open effort” blogging in terms of reading and releasing competing applications.  There – I said it. 

Hopefully the next instalment will be later this week and be a lot less wordy.

Scott 

Bookmark To:

Feel Recursive? Tweet it!