I've gotten some really good feedback. Thank you very much. In my initial brainstorming, I decided that the client/server model would be much preferred as well. Not only is it more simple, but it is more flexible (for example if a company wants to buy credits that can be shared across multiple computers). However, in this specific case, the report generation will often happen when an Internet connection is not available. Hence my sticky situation. So I came up with "plan B" which I reported to you all. I was hoping that my plan B was terrible and that there was a much better way of doing it.
So, my overall takeaway is that we're going to have to deal with a sketchy situation or change the business model. It's not my call to say which is better. But at least now I have more information to influence a wise decision. Thanks for all your help! Dustin McQuay On Thu, Jun 25, 2009 at 3:24 PM, Stuart Jansen <[email protected]> wrote: > On Thu, 2009-06-25 at 14:59 -0600, Alberto Treviño wrote: > > Even in "cloud" or "rainbow" computing you could charge for the service. > > You can even write a traditional desktop application as an interface to > your > > service. Hence, the license management is set at the server where it is > > more difficult to crack. > > By exact opposite, I meant: You're going to have to purchase and > maintain the infrastructure. Cheating by offloading the purchase and > maintenance of hardware while charging based on utilization of the > hardware is doomed. (And also rather rude.) Increasingly, customers > don't pay for software, only services. The more service you provide, the > more customers will consider paying. > > -- > "XML is like violence: if it doesn't solve your problem, you aren't > using enough of it." - Chris Maden > > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list >
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
