Licensing Systems for Xojo Applications

For years we’ve been using eSellerate for purchasing and licensing and registration of our apps.  We’ve recommended it to clients too and, for the most part, it’s worked quietly, steadily, and hassle-free for many years.  Their plugin is still using the old Real Studio format and they’ve said in several emails that they will not support Xojo going forward.  With Xojo moving to 64 bit in the R3 release it’s time for us to look at alternatives.

We liked eSellerate for a number of reasons.  For one, it was pretty simple.  Once you learned the intricacies of their web portal it was easy to add products.  Their sample app sucked but we figured out a better sample and offered it as an example for others on our website.  After years of using them I could set a new product up in as little as five minutes.  Then, they handled all of the various sales taxes and VAT for the states and countries that need it.

After the purchase, eSellerate would send an email to the user with purchase details.  This included license code, download instructions, and any other messages that we wanted to give them.  And all of this without any intervention on our part.  It just worked.

eSellerate also has an in-application purchase which we found to be pretty useful.  Users could purchase the application without ever having to leave the application.  For some people this was a nice feature but I’m not sure how necessary this is any more.  Lot’s of people purchase things over the internet with no qualms.

When it came to the registration part of things they had a number of nice features.  I could control how many machines could be activated with a single license.  This led to some instances where users didn’t deactivate a license on an old machine and couldn’t activate it on a new one.  However, a 30 second trip to the eSellerate web portal usually solved this.

On very rare occasions we’d get a user that couldn’t activate an app because of security restrictions on their network.  To solve this eSellerate had a manual activation process that would bypass all of that.  It was kind of tedious but then that’s why it’s called a ‘manual’ activation.

Bundling products together was pretty simple and even setting up payments to a third party was easy.  It was flexible and I know it was used in a number of bundle offerings over the years because of its simplicity.

So now we are on the hunt for the next purchasing/licensing/registration system.  We could write our own but I really don’t want to do that for a lot of reasons I won’t go into here.  Ideally, we’d find an existing system that integrates into our website that takes a variety of payment types and also handles sales taxes.  The last thing I want is to get hounded by a government entity – I just want that to happen automatically.

I’d also like to keep the per machine registration with restrictions on how many activations a single license can do.  It must work on Mac OS X, Windows, and the most popular Linux distributions.  Not that we have a lot of Linux applications but we have some and I don’t want two different systems if I can help it.

The in-application purchase and registration was nice but that’s not necessary any more.  I think most people are comfortable now buying over the internet.  However, offline activation is still something that is a requirement.  There’s no telling where customers are and what security restrictions are in place.

I guess the other part of the equation is that I, nor or customers, need something them an arm and a leg.  I’ve see a few licensing schemes that want $300 per product per month.  While they seem really nice, that’s above and beyond what we want and need.

A few names that have come up recently are LimeLM, Paddle, FastSpring, and I suppose even the venerable Kagi is in play.  FastSpring is more of an eCommerce front end so what are you using for application licensing?

What I’d like, Dear Readers, is for you to share your experiences, both positive and negative for any of the services listed.  Have any missed any that should be on the list?

Features, Roadmaps, and Pricing. Oh my!

Lot’s of drama on the Xojo forums the past couple of days.  People are gnashing teeth at perceived slips in timeframes that were really estimates at the 2013 Xojo Developers Conference.  There’s also some gnashing of teeth going on whether or not Xojo Pro licenses will include iOS ot.

Xojo has a number of options in regards to feature sets, timeframes, and pricing.  Let’s review:

One:  They tell us nothing and release new features when they feel they’re ready.  Always an option but not satisfying to the users especially at developers conferences.  We go, in part, to find out about the new and upcoming features and provide some feedback.  Without this information it’s hard to get excited about future releases.

Two:  They tell us about possible features and give rough timeframes.  They’ve done this in the past and it seems that once they say it, people assume that’s it’s gospel and that it will be in the next release.  It doesn’t take long for people to complain about ‘missing’ features but at least the new features get released – eventually.

Three:  They give us a timeframe and release regardless of whether it’s ready or not.  It’s been a while, but I can remember new ‘features’ that did not work.  Period.  Not how I wanted them to work or even how they intended it (as in demo projects didn’t even work as intended).  Thankfully they don’t pull crap like that anymore and I can’t imagine anyone wanting to go back to that.  Trust me, that lead to very pissed off customers and people leaving the community for good.

Of those three options, option two is the only viable one and is a balancing act.  Unfortunately it leads to speculation, misinformation, pissed off users, and much trumpeting of outrage (real or feigned).  I can live with this because option 1 is hard to deal with as a professional users and option 3 is simply unacceptable for any developer.

Pricing is a bit trickier since the new licensing scheme lets anyone use the IDE without buying a license.  If you wish to build a final executable you need a license for the target.  Theoretically, this should mean that when Xojo iOS is released anyone on a Mac can test it.  It’s only when you want to build you’ll have to buy a license.  Currently, Pro users can build for all known targets targets (note that this does not include iOS).

The question everyone is asking:  Will current Professional license holders have to upgrade or will iOS be included?  As with features and roadmaps it’s an irrelevant question right now.  You either need the Pro license or you don’t.  Forget about 3, 6 or 9 months from now.  Buying a license now for a feature that doesn’t currently exist is kind of pointless.  Get what you need now.

Honestly, I doubt that iOS will be included in current Pro licenses.  Maybe I’m wrong but iOS is a HUGE deal.  Perhaps the biggest deal Xojo/Real Software has ever done.  If it were *MY* company iOS would be an additional cost even for existing Pro users though I’d give a nice discount for early adopters since there is a risk for those developers.

So my bit of advice is to hold tight.  The 2014 Xojo Developer Conference is towards the end of March.  That’s not very far away and in realistic terms it means that Xojo is already preparing for what they’re going to talk about at at the conference.  I’m sure they already know what new features, updates, roadmaps and pricing they are revealing.

Watch this blog and I’m sure I’ll be writing about all of these things.  Just take it all with a grain of salt.  Oh, and I’m sure we’ll be reliving this conversation about the same time next year.

When a License Isn’t a Valid License

I will preface this post with the usual disclaimers:  Not everyone will have this issue nor will it even apply to a vast majority of Xojo developers.  Take it with a grain of salt and if you disagree, that is your prerogative.

This week we had a little lull in the development of one of our bigger consulting projects.  It’s a Web Edition project that has 300+ web pages, 250+ WebContainers, 97,000 lines of code and compiles down to about 43 MB of code.  It’s a monster and we’ve been maintaining it in Real Studio 2012 R21.  This week we decided to upgrade it to Xojo 2013 Release 3.

We have 3 full-time developers and a DBA/QA person who is familiar enough with Xojo programming to fix some of the simple stuff.  We already had 2 Xojo pro licenses and bought a 3rd for our other full time programmer that had been working on this project.  The 4th team member won’t ever compile but will need to be able to save in the version control format that we use on all projects into Subversion.

Being a responsible and conscientious user I read the Xojo End User License Agreement (EULA).  Here is what it says:

• A Xojo License Key is required to save a project in Text or XML formats.

With that fairly plain English we bought a desktop license because it would be the most likely be relevant in the future for our 4th team member (since most of our work is desktop apps).  When our team member applied the license and worked on the Web Edition project every time she tried to save the IDE kept doing a Save As in binary format.  Obviously something was wrong with the licensing.

After checking with Xojo Inc. we discovered that the licensing text was incorrect, or at best misleading.  You need the target specific license key to save a project in Text or XML formats.   In other words, to save in Text or XML for a Web Edition project you need a Web Edition license, to do the same thing for a Desktop project you need a a Desktop license and so on.

For us it was not a huge deal.  We needed it so we bought another Pro license and Xojo Support quickly lupgraded our license.  I understand the reasoning behind it but the fact that I looked it up in the EULA just to make sure says the EULA language needs some additional clarification.  I was pretty mad at the time because it wasted my time and a team members time for a half day while we got it all straightened out.

So be aware of those restrictions when you buy Xojo for your team.

Xojo Licensing Changes

Xojo, Inc. confirmed last week that the licensing for Xojo is changing.  The IDE now costs nothing.  Free.  Zip.  Zilch.  Nada.  Now we all know that it’s awful hard to stay in business by not charging any money, so the catch is that to make a build you need a license.  If you’re building for desktops (Mac, Windows, Linux) you need a desktop license.  Building for Web you’ll need the web license.  Building a console app you’ll need a console license.  The only oddity in the mix is if you’re using database servers which requires an additional license SQLite is included in all licenses).

Now that the IDE is free all users can take advantage of all Xojo features.  Item encryption, server sockets, SSL support, database encryption, remote debugging, container controls, code profiling, IDE scripting and build automation are the big items that were not available to all users depending on what license they had for Real Studio.  This has some advantages for training and getting people to actually use those features.  Everyone has the same set of features and all are available on all supported platforms.

Announced Pricing is this:

Console Licenses $100 ($50 renewal)

Desktop $300 ($150 renewal)

DB Servers $300 ($150 renewal)

Web $400 ($200 renewal)

So what does this mean for those with existing Real Studio licenses?  Real Studio personal licenses automatically get a Xojo Desktop license.  Real Studio Professional get Desktop, Database, and Console licenses for Xojo.  Real Studio Web licenses get converted to Xojo Web and Database.

Real Studio Enterprise licenses now get what’s called Xojo Pro.  Xojo Pro gives you all licenses.  You get desktop, console, web, and database licenses.  It comes with Priority Support which means that Xojo Inc. will handle all Priority Support issues first and then everything else.  Pro licenses also work on three machines (in contrast to the two for other licenses).

Another feature for Xojo Pro is that it gives you guaranteed access to the beta’s.  The Real Studio beta list really had no restrictions.  You signed up and you got access.  They didn’t say this but I suspect this is in response to the many people on the beta list that never reported anything but generated a ton of useless chatter.  This will definitely cut down on that problem.

Some people have taken offense to this.  They are not going to be Xojo Pro users so they feel that they’ll be cut out of the beta list.  The wording in the keynote was very specific.  Xojo Pro gives you ‘guaranteed’ access to the beta list.  That does not mean that you can’t join the beta it just means that it’s up to their discretion.  Those that have contributed in the past will most likely be welcome.  Those that have not are probably out of luck.

Another advantage of getting a Xojo Pro license is access to a Xojo Pro Only forum.  They figure it will most likely be the full-time developers (such as BKeeney Software) that use it.  Honestly, I have a problem with this even though I will most likely have several Pro licenses.  I have been a top 10 poster in the Real Studio forums for many years and I just don’t see how this helps me, or the community.  It seems like it will introduce some stratification into the community where there is none now.  I can’t imagine having an issue that I wouldn’t ask the entire community about.  I could go on about this but it seems to me that it’s a marketing bullet-point to make Pro look better.  I think it’s a bad idea and probably won’t use it.

The final ‘advantage’ of the Pro license is that Feedback cases now get a 3x multiplier. Real Studio licenses are a little different.  I believe Personal licenses get no multiplier, Pro/Web gets 3x and I thought that Enterprise licenses now get a 5x multiplier.  So in this scenario everyone else gets no multiplier but Pro users are the only ones to get it.

The Feedback multiplier isn’t a huge change but it definitely favors the Pro license.  I like this but I have my doubts that it will change anything significant.  As a pro user I have needs that are not being met by Real Studio (and now Xojo) despite many years of blogging and generating feedback reports.  Instead they have consistently gone for marketing bullet-point solutions and solutions that make it easier to sell to beginner and hobbyist developers.

Don’t get me wrong.  The free licensing has the potential to introduce Xojo to a lot of people that would consider themselves hobbyist or part-time developers.  That’s a good thing.  But it’s the folks like me (the Pro’s) that spend serious cash.  I want and need features that a) make my development life easier or b) help make me money (usually in completing things faster).  Not a whole lot of those types of features have been introduced in the past five years.

What do you think about the new licensing and the Xojo Pro features?

eSellerate Issues with Real Studio

Even though I’m a consultant, I still believe in the axiom that “Time equals money”. So while I don’t have a problem creating my own solution, if there are existing solutions out there I’ll use them. This is why I have the full suite of Einhugur and MonkeyBread Software plugins (including Chart Directory and DynaPDF) to name a few. I acquired the Formatted Text Control and Simple Help Editor when they became available because they scratch an itch that we have as Real Studio developers and they save me time in one form or another.

One item that seems to come up with regularity in our products and for our clients is licensing and registration. Add in web store functionality and it becomes a can of worms. Not that you can’t do it yourself, but most developers (and clients) are in the business of selling their products, not coming up with solutions for web stores, licensing and registration.

For several years we used a web only solution called phpAudit. It worked okay, but the the software wasn’t designed with desktop applications in mind. We made it work but it wasn’t ideal. For one, it required a web connection to check registration and the only way to purchase was through the web and the only payment option was PayPal. Again, we weren’t unhappy with that solution. Heck, several of our clients still use it and are happy with it.

We made the switch to eSellerate for our own products a few years back. It’s a decent solution with a web store solution AND an integrated store so users never have to leave your app to purchase the software. It can accept payment from credit cards in addition to PayPal and several other forms of payment.

It has an offline mode where you can still activate the software even if the end user machine doesn’t have an active internet connection. This came in handy when someone purchased our software while on a ship traveling the South Pacific.

I have had many conversations over the years with people who despise third party solutions like eSellerate because if their service gets broken/hacked then their apps get broken too. This has happened at least once in eSellerate’s history but not recently. While I can’t disagree with their reasoning I find it amusing that they’ve spent an inordinate amount of time trying to come up with their own unique licensing/registration solution. Remember my opening statement about time equals money?

eSellerate requires a plugin for Real Studio and it works on Macintosh and Windows. Until recently there have been zero issues using this plugin. The switch to Cocoa took eSellerate a while to come up with a solution (that you have to ask Support to get, by the way) but that’s okay since Real Software’s Cocoa solution has been in beta for a while.

In Real Studio 2012 Release 1 the plugin API was changed slightly to make applications a bit safer. Until then it was possible for a plugin developer to do some unsafe things and this might have caused instability and hard crash issues. Many plugins worked just fine in this transition but the eSellerate plugin was one of the casualties. Ironically, the Macintosh (Carbon and Cocoa) version works fine but the Windows side of things crashes the application when certain plugin calls are made.

I know there are others who have reported the issue as well, but I first reported it in October of 2012. Since then I have received several updates from them with this being the latest:

I’m afraid I have some bad news.  As you know, we’ve lately had an engineer working on a daily basis to try and resolve the issue with Windows apps crashing if compiled with REALStudio 2012.  The folks at Real Software had been awaiting the results of our engineer’s investigation to try and troubleshoot further.

Unfortunately, as of last week, our engineer who had been working diligently on this case is no longer available.  I’ve taken this matter up with my manager, the director of eSellerate, and she has escalated it above her as well, trying to get some dedicated engineering resources to get this taken care of.  However, it doesn’t appear that we’re going to be able to continue the investigation in the immediate future.  We’re not sure when we may be able to resolve this.

We do understand how important this is for your continued integration with eSellerate, and we sincerely apologize for the trouble.  I’m very sorry I don’t have better news for you.  If it might be possible for you to integrate with a 2011 version of REALStudio, that might be your best bet for the time being.

This is not good news and their proposed solution is less than ideal. As the 2013 release nears completion this issue will continue to grow. Eventually Cocoa will be the defacto build for Macintosh and there will be features in Real Studio that can NOT be reverted to 2012 R2.1.

Because we’ve developed plugins for Real Studio I offered our services to eSellerate. I also contacted Geoff Perlman, CEO of Real Software, to see if they could help. RS has also offered to fix the plugin for eSellerate. So far neither RS or I have received any additional feedback.

So now I’m stuck between a rock and hard place. I can assume that eSellerate will fix their plugin but I’m currently advising one client NOT to do so. What’s the point of converting their entire user base over to eSellerate if they’re going to abandon the Real Studio market. Now, I’m not suggesting that they are, but it’s been four months and they don’t appear to be any closer to fixing this bug then they were in October of 2012.

If I go with my motto that time equals money what are the other solutions out there that handle payment, licensing, and registration in one package with Real Studio applications? I know of Kagi and FastSpring that are being used by some Real Studio developers. What are you using?  I’ll look at just about anything.

It’s Your Party (i.e. GPL Licensing)

Special thanks for John Gruber over at Daring Fireball for finding the post at http://www.red-sweater.com/blog/825/getting-pretty-lonely

I don’t know about you, but I’ve had serious concerns (like most of the REALbasic community) about using MySQL database servers because the GPL-style licensing makes me nervous.  I’d love to use it but if it means I’m on the hook for licensing fees and/or have to release my source code of my apps that use I’d much rather not bother with it.  ARBP did a survey last fall that pretty much showed MySQL usage down 20% and PostgreSQL (which has very liberal licensing) up about the same amount.

Any way you slice it, to us mere mortals the GPL is vague at best.  We’re programmers for heaven’s sake!  We don’t write vague code because vague code doesn’t work.  Be explicit like the MIT license – it’s clear and concise and is far from ambiguous.  I think the GPL should be rewritten to make it explicitly clear.

I didn’t mean to start a whole blog post about someone else’s blog post but I know that there are a lot of questions about GPL and what it means to the developer.  What are your thoughts on the GPL?