Scott Raney wrote:
> On Tue, 03 Aug 1999 Michael Fair <[EMAIL PROTECTED]> wrote:
>
> > the license would be GPL with the
> > additiional clause "Standalone executables are explicitly declared
> > to be distributed under any license the author so chooses." and be
> > done with it.
>
> Seems to me your licensing proposal completely eliminates any
> protections the GPL offers. All I'd have to do is attach a single
> empty stack to the OC engine and then I could sell it as "UltraCard"
> without any requirements to distribute source code or even give
> copyright credit. Not that I personally think this would be a such a
> bad thing, but you might as well just do a public domain license in
> that case as it gives you equal protection without the burden of
> having to explain the terms to every new person that comes along.
Let me ask this, if you don't personally think this would be
such a bad thing then why do we let some made up concern
about the other guys stop us from going with it?
We could have said "I don't think this would be a bad idea"
and then let the guy who thinks it's a bad idea speak for
himself.
That is one practice, worrying about things we personally
don't care about, that I say keeps us stopped. If we care
we should say something, if we don't then let the people
who care say something. When and if you start caring then
say something.
But to go ahead and address it now that it has been brought
up, I agree with you completely that you could absolutely
release your new product "UltraCard". However I, as
an OpenCard developer, don't really care.
Here's why: "UltraCard" is now a static piece of binary
code, and it's simply a matter of time before everyone on
the Net knows what you are doing. Someone would find
out, and then they or we would post to the appropriate
newsgroups a simple matter of fact "If you are thinking
about buying UltraCard just go download OpenCard", and
then slashdot will go on a rant about how big business is
trying to stop the OpenSource guys, and then we'll get a
few "I told you so" from the people who saw this hole in
the license (completely missing the point that 1,000 more
people are now downloading and using OpenCard because
of the publicity), and in the end "UltraCard" will just be the
laughing stock of the project because you could have just
sold "OpenCard" in the first place and then taken advantage
of the fact that we are doing your upgrades for you, and
hopefully you'll be hugely successful because then you'll
want more success and you'll want us to produce more
code, which means you need to get more of our time,
which means you'll need to pay us and give us hardware
because what we have is too slow, and you will host our
web sites and download sites because we are making you
money. And this whole success thing just makes everyone's
life easier. On the other hand, if you fail, "OpenCard" still
has nothing more to worry about, but we didn't make any
money, hardware, or resources off of your failure.
Let's see "UltraCard".... they make me pay for a kick ass
scripting engine and development tool, and on the other
hand "OpenCard" gives me the exact same kick ass product
but for free, and they give me the source code.
You decide... I'm not concerned about the "UltraCard"
clones, those guys are like 2% of the problem, and
they will simply be unable to compete with OpenCard.
At the same time, by not concerning ourselves with them
we gain much more freedom with our licensing issues
because we don't invent the "perfect" license. We can
be happy with something close.
I assert the bottom line to our success comes down to
"How many features that our customers want did we
create today, and how many new downloads did we
have?" We focus on making those numbers really high
and we couldn't help but succeed beyond what we ever
imagined.
As the project grows there will be a time where the
single to noise ratio on this list will diminish, but we
can prolong that by keeping the conversation focused
and becoming rigorous about only responding to
conversations that are going to move the group forward.
As we practice that, we develop a culture in which people
are committed to that and further that practice. People
copy their leaders. And we ladies and gentleman are
their leaders, they will copy us. If go around in circles
on things we don't care about, so will they. If we spend
most of our time talking about what code we changed,
or gave recommendations to the maintainers of code we
would like to impact then they will only have those
conversations too. And those conversations mean more
code and constructive ideas, which lead to a better
product.
> While I can sympathize with your frustration at the apparent lack of
> progress being made on the organization and licensing issues, a quick
> ill-considered fix is worse than no fix at all IMHO.
Thank you for sympathizing, it does make a difference.
However, I disagree. An Open Source project is totally
dynamic. Just because we did something today, says
nothing about tomorrow. Larry Wall summed it up pretty
well when he said, 'I don't know what language I will be
programming with in the future, but it will be called PERL.'
If we make a mistake, we simply correct it. If there are
three ideas on the table, and none are a clear-cut winner,
let the guys who want to see it their way implement it, then
we have all three and we can set some compiler options and
see which one works out best in practice. If that is
impractical, then get into a rigorous conversation along the
lines of: "We should go this way because ... " and let the
others do the same and then look at the evidence. We are
intelligent people on this list and I would rather have a poor
implementation than no implementation, because a poor
implementation gives me at least an implementation so I can
use the feature, and it creates an itch for some programmer
to scratch and get involved, it is also much easier to do it
"right" when you can see "what they did wrong."
My concerns are actually having people write engine code,
and actually having people write documentation.
I consider these people a scarce resource and would
rather empower the guy with the mediocre ideas but
the source code to prove it, then the guy who designs
the perfect solution but never gets around to writing
the code. The ideal solution is the idea guy supports
the coder, however in my experience it's rare that
people do that unless it is considered the normal
way of doing things in that culture.
I am not concerned with UI developers or about beta
testers or even people who are willing to "throw in their
ideas." I believe we have plenty of those, and we need
every one of them, however we have a breakdown around
allowing our coders to start coding because we don't have a
license to release under yet, and we don't have a license
because we don't have an organization, and we don't
have an organization because we can't decide how it
should be set up, and we can't decide how it should
be set up because we can't decide whether to elect or
to come to a consensus, and we can't decide that because
we don't have any authoritative body which just dictates
that it is going this way or that, and we don't have an
authoritative body because we can't decide how the
organization should be structured.
I say we just follow the guy who says "I will lead the way"
and if he sucks then we stop following him, and
start following someone else. It's difficult to be leader
when no one is chooing to follow you.
-- Michael --
