2009/8/24 Ian Wood <revl...@azurevision.co.uk> > > On 24 Aug 2009, at 10:14, David Bovill wrote: > > The argument for removing the ability to password protect stacks is a good >> one (thanks capellan) >> > > So far the arguments that I've read in the thread could be summarised as > 'other things are limited in revMedia, so this should be as well to make > people upgrade'.
True - no one likes that. I especially did not like it with regard to SSL functionality :) But you've got to admit it is in everyone's interest to maintain strong incentives for people to upgrade and therefore provide RunRev the revenue stream they need to keep developing the language. I'm interested in tools, licenses, and social media that encourage collaborative efforts - whether open source or simply online communities and user generated content. In that context I'd argue that creating a free environment in which *the code is unlockable* and encouraging open source licenses for such code is technique worth considering for any company aiming to increase the user base for a computer language. It is controversial because we don't have good studies (yet) around these issues. It would be interesting to ask whether a version of JavaScript that allowed the code to be locked would have taken off more quickly or slower than JavaScript that you could not lock, and everyone could read, hack and learn from? We simply don't know. In the case of JavaScript - my guess is that allowing the code to be locked would have quite seriously damaged it's uptake and stimulated java based solutions. However I'm not coming down hard on either side - I just think it is a good question. My intuition on this lean towards 1. Preventing locked/closed code suits organisations with small language communities and where developing robust user generated libraries is a priority. 2. I'd lean towards the "allow locking/close sourcing" for larger or established language communities, with a wide array of existing libraries, where you want to encourage commercial language markets for components. But then there is no good evidence either way for this - all we can do for now is keep a close eye on these collaborative communities and see what works and does not through trial and error. _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution