Vote to disable password protection for revMedia 4 stacks

[David Bovill]

2009/8/24 Ian Wood <revlist at 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.