[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MetaCard (was: Re: Logo)



Scott Raney <raney@metacard.com> wrote:
> > Or, is it to say that you could create the application, but that users 
> > could only use it under the terms of the Starter Pack, i.e., with a 
> > limit on the length of scripts, etc., before they have to pay for a full 
> > version?
> 
> It would be limited by the MetaCard Starter Kit limits, yes.  As I
> said before, the package I was envisioning would basically be
> HyperStudio with no HyperLogo (or more precisely, only very limited
> scripting).  But scripting certainly wouldn't be required to do
> anything most people do with HyperStudio because navigation in that
> package is all based on data structures, not custom scripting.

How are the Starter Kit limits defined?  Is that a hard limit put in 
the software, or a limit the application has to put in (to be in 
accordance with the license)?  It seems like a reflective language 
makes the issue a little funny (assuming MetaTalk is reflective -- 
but I suppose it must be if it can write its own editor).

Would computer-generated code be included in the limit as well?  I 
doubt much would be necessary, but I can imagine that the 
dynamic behavior of a HyperStudio-like stack might imply at least 
a smidgen of code.  Well, maybe not... anyway, if it did, would that 
count?

> > I'm not entirely sure what you are thinking about here.
> 
> The only unexplored issue here is getting the original development
> team going.  They would get started by just getting MetaCard K12
> licenses which would require that they be currently affiliated with a
> school, or by getting a standard license via a grant from MetaCard
> Corporation (which is usually pretty liberal about this kind of
> thing).  

So you are saying that someone could (possibly) get a MetaCard 
license for free to work on this?  (How much does the K12 license 
cost?)

This would probably be important if it was done by volunteers, 
which is what makes up most of the Linux community.  Even if, in 
the big picture, a few licenses aren't that expensive, there's no 
infrastructure to share payment of such things and it would end up 
being a signicant block to the project.

> Once the first release is made, some aspects of the program
> could be changed by people using the free Starter Kit version of
> MetaCard (notably doing language translations of the prompts or doing
> minor customization of the UI like change the size, color, or
> positioning of the UI elements).  Anyone with a K12 or regular
> MetaCard license would be able to change any aspect of the program,
> assuming the original developers choose to allow this (which I would
> assume they would, at least if were an open source project).  

This is where there's a real challenge to fit it into the open source 
development model.  Freely available development tools underly the 
entire system.  I think something made in MetaCard could certainly 
be free (as in beer), but it's hard for it to be free (as in speech) in a 
meaningful way when a license is required to modify it.  In all 
practicality, it is unlikely anyone outside of the main/initial 
developers will make contributions.

That doesn't mean it couldn't be successful anyway.  In reality, few 
of the users of a HyperStudio-like application would even consider 
changing the program, not to mention being skilled enough to.  It 
isn't high on the priority of most teachers -- though there does 
seem to be some significant (in terms of passion, not numbers) 
teachers who do like to toy with the programs they use.  The need 
to get a license -- even if a K12 license is cheap -- would probably 
exclude them from this potential.

It seems like it's mostly a strategic decision.  Even though one 
would have to forgo most of the benefits of an open development 
model, it would still probably be the easiest and most successful 
way to make a HyperStudio clone.


This all seems very complicated, but I suppose the situation must 
be quite simple compared with other similar dealings in the 
proprietary world.  It's all foreign in an environment where the 
biggest problem in aquiring and changing a program is slow 
connection times and the occasional compiling problem.


--
Ian Bicking <bickiia@earlham.edu>