On Sun, Jul 3, 2011 at 7:03 AM, John Craig <j...@splash21.com> wrote: > > > The scripts are protected - if I can generate some revenue from the plugin, > then I can dedicate time to developing it further. >
I'm not sure exactly the correlation between scripts being protected and generating revenue from them. I've been involved with this community since the very start and can't recall anyone ripping off someone else's scripts, thus causing a loss of revenue to the developer. Furthermore, I have seen several tremendous libraries for inclusion into codebases which are non-protected-- and the developer does well (for instance Ken Ray's excellent all Transcript XML library: http://sonsothunder.com/products/xmllib/xmllib.htm ) I suspect if you asked around, you'd find many of the commercial developers aren't fond of using protected libraries at all. They can present a number of problems for a developer and their client if/when things go wrong. So, basically by protecting the scripts, you're effectively locking out some potential customers. I can more understand developers protecting scripts when those scripts are part of tools which don't end up inside the codebase of another developer's project. For instance it might be a good idea to protect a plugin script which acts as a debugger for a project. Even so, I think many are still unlocked because mostly folks here are more eager to share how things are done, rather than hiding how things are done. At Altuit, we've developed for sale add-ons to Rev since before revSelect even existed-- among the more popular altBrowser (which became revBrowser), altSQLite (which became revSQLite), along with the libraries which went with them, and all of the scripts and libraries were unlocked. Also, the source code for the different tools was available in case anyone had an issue. Still, it certainly is your decision. I will support your product, and the fine work they represent, by purchasing a copy anyway. Hopefully in the future you'll consider unlocking the libraries. > Then again, if I decided that using LiveCode was too hard to support > because I didn't have the source code, and started writing my own cross > platform development engine, things would take quite a bit longer ;) > Yes, but they do let you have access to the whole IDE (but the licensing code) from wthin the LiveCode IDE. > The community is small at the moment, but I'm excited about how LiveCode is > progressing and the things that are in the pipeline. I'm hoping that the > small community is replaced by a huge community. > Yes, we've all been hoping so for several years now. > There is a tab control on the way - I'm trying to build a full feature set. > The plugin is still in it's early days, and by no means perfect. I've > still got a couple of support tickets to sort out just for buttons - the > feedback and bug reports have been excellent - really helping to shape > things to come. > Is there a known list of problem areas? Might be helpful if there are more than a few. > Great presentation last night, BTW - I enjoyed it. There are a couple of > techniques that I've discovered during the development of MobGUI that I've > thought "hey, that could be a good topic for LiveCode.TV", so although it's > not open source so far, there's nothing stopping me sharing ideas and > interesting bits and pieces with others! > Just so you know, unprotecting your scripts does not equal making them 'Open Source.' Unprotected scripts still have the protection of copyright law. I'm not the biggest OS advocate, and I do agree you should be able to create revenue from your hard work. _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode