How do you manage customer WAS updates: YOU purchase or THEY purchase?

[RichCPT]

So, I'm looking at selling a product developed under AlphaAnywhere and I am wondering what other developers are doing to manage WAS updates on the client computers to match your own program updates. Here's some specific questions:

1) Does customer need to be on exact WAS build number as the IDE used to publish the application or are some differences allowed and how much?

2) Do you purchase the initial AlphaAnywhere license for the customer by building the cost into your product?

3) Where do you have the customer download the WAS server from? When I look at the Alpha web site they don't seem to maintain different versions that my customers could download.

4) After the first year of the customer's initial WAS purchase do you have them obtain their own new WAS subscription to get updates or do you build the cost of annual WAS subscription into a maintenance fee you charge?

5) How many separate source code versions do you maintain to go along with the various WAS updates and do you use a version control system for this, which one?

[TheSmitchell]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

1) Does customer need to be on exact WAS build number as the IDE used to publish the application or are some differences allowed and how much?

They must match. You can either require they always be up-to-date with your dev version, OR, you keep a record of what version the project was built in and only apply updates from that version --- you can download older versions of Alpha from the web (the link is at the bottom of the downloads page.) You may want to keep a backup of each installer for every version you deploy if you're going to have a policy of only updating a client's project using the version that matches the WAS they're running.

3) Where do you have the customer download the WAS server from? When I look at the Alpha web site they don't seem to maintain different versions that my customers could download.

Alpha does maintain different versions of releases. The link to previous versions is at the bottom of the download page. If you deployed someone on a Pre-Release, that's potentially a problem since Alpha does not maintain a listing for those installers. So, keep your customers on an official release.

5) How many separate source code versions do you maintain to go along with the various WAS updates and do you use a version control system for this, which one?

Always use version control for any project. Always always always. I use Git for work. Another popular system is Subversion. Look at the tools available and pick the one that you feel most comfortable using. If you work in a team, you may want to consider the strengths & weaknesses of branching and merging.

[RichCPT]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

Thanks Sarah for your responses and especially for pointing out the "Previous Updates" link on the bottom of the Alpha Anywhere Update Page - I had either missed that or not thought about it. But those links only seem to include the patches. I don't see how a new customer could start out with a specific official release version. I will ask Alpha on this one.

[Steve Wood]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

The answers to questions 2 and 4 are really up to you, and your customers. It will be different in each case. It was easier when Alpha had "versions" like 9, 10, 11. You could build in V9 and then expect the customer to just stay there until they needed something new. Then it was up to you as a developer to either provide services in the older version or tell the customer they have to upgrade to work with you. There are customers who hate to upgrade if it will cost them, and customers that always want to be on the latest. I personally always worked with the current and one version older. So currently I work with Alpha Anywhere and Alpha Five V11.

Its a little more difficult (or perhaps easier depending on how you look at it) with a subscription based Alpha Anywhere. There is no hard "cut off point" where you and the customer can agree to keep things on an older version. Although it has not happened for me yet, if an Alpha Anywhere customer came to me for updates to their system, they would have to be on a current subscription with the latest patch. I cannot maintain separate copies of Alpha Anywhere for each customer, all on different patches. I don't know if it is accidental or ingenious by Alpha but it forces both customer and Developer to keep up on their subscription. At the same time if the customer does not need any updates, they can sit on a non-updated version of Alpha Anywhere for a long time before some browser or O/S-based issue forces them to upgrade (that happened where Alpha V11 Web and IE11 do not work together).

On your question number 2, personally I stay out of my customers purchase of Alpha Anywhere, even though I could make some money on the transaction. Even if I process the order, I put their name on the subscription and have Alpha bill them directly. You can actually buy all of the Alpha Anywhere products on the IADN website at a slight discount off list price, but it has never worked out because I cannot keep up with all of the deals coming out of Alpha so I (and potential buyers) never know if the IADN price is higher or lower than Alpha real current price.

Having said that, I do like your item number 4. I can envision writing a multi-year contract with updates to Alpha Anywhere included. I still would not want to be holding on to a bunch of subscriptions (being obligated to pay Alpha) in case my customer(s) decided to NOT pay for those subscription. I can see working that out though.

[RichCPT]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

Thanks Steve, fantastic input. This is our first experience selling a product built on the Alpha platform and having to deal with a 3rd party cost and frequent 3rd party updates. We've always charged an annual maintenance fee with our product that includes technical support and software updates for the period. It becomes a little more challenging coordinating a second annual cost into that that we would have to pay out, especially since our customers lag behind in payment by months at a time! Certainly, we hope most of the customers will opt for our hosted SAAS solution.

[Clipper87]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

You may want to take a look at the IIS beta, that will be offered as a service as well on Amazon. In IIS you can indicate what AA release a webapp should be using so you can have multiple releases running. IIS is really the way to go , just sit & wait a little longer. iis1.pngiis2.png

[bea2701]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

What Alpha is doing is almost the same as other vendors like Syncfusion, Telerik etc. The only BIG difference is that Alpha delivers a full stack without the need of other tooling to get the job done. In essential directing Mobile because that is the market to make money at present. So Alpha delivered a Mobile solution to support there customers and developers to make it possible. I have not seen any other vendor that will come close to what Alpha promises. And I have have seen most of the like Infragistics, LightSwitch, Devextreme,CodeOnTime in the past year. There all "flirting" the market with solutions in fact some are did a good jon and lost but in essence it's not complete. It's clear Marketing is following a new direction simply to heavy invested time,money and resources to get the Mobile product upto to market for that it has a price to pay and investors want ROI. So the strategy and vision changes to a other level. The new subscription model is choice of best in the eyes of Alpha management team but i see also that it will not work for every-bodies business case. Simple fact you have to make choices unable to make everybody happy there will also be some loss, they take it as acceptance risk. Every business project so it is up to you make the right choices. Some business types like small volunteer organisations simple can't pay the Alpha model, otherwise there happy with a good well thought webapps for the middle term and don't need but would like to have a mobile apps. Frank's advice is correct to keep an eye on IIS.

[kkfin]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

Frank's advice is correct to keep an eye on IIS.

Maybe year ago but I am sure that Alpha team is now 100% focused to nodejs and V8 engine. First their problem in web development was dbf and still the problem is xbasic in server side.
What ever they do with xbasic and IIS is just not enough anymore. It is totally waste of time and money.

Now Alpha has opportunity in bringing JavaScript to the server side and they certainly will do it. Then every door is wide open in IT departments for Alpha developers.

[Clipper87]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

>>Now Alpha has opportunity in bringing JavaScript to the server side and they certainly will do it

They are currently busy doing that

[Peter.Greulich]

Re: How do you manage customer WAS updates: YOU purchase or THEY purchase?

Just to throw in my 2-cents:

1) Does customer need to be on exact WAS build number as the IDE used to publish the application or are some differences allowed and how much?

They don't need to be the same. Generally speaking, however, you want the WAS to be equal to or greater than the developer. You can even publish w. a newer version of the developer than the WAS - IF you don't include new features. I have done that (too) many times successfully. But, yeah, keep'em the same if you can.

5) How many separate source code versions do you maintain to go along with the various WAS updates and do you use a version control system for this, which one?

I agree, it can be a hassle if not a mess. I keep copies of builds I use, but like Sarah said, beware of using pre-release builds, unless you download both the developer & WAS at the same time. Even then, verify that the build #s match. Things can change really fast in pre-release land.