[om-list] Re: MTShell and 4C

[Mark Butler]

Tom,

  The MPL is just fine - its practical effect is similar to the LGPL,
in particular you can mix MPL components and proprietary components in
the same executable. Of course, if you want jurisdiction in some place
other than Santa Clara County, California you will have to modify and
rename the license.  

MTL / MT Shell sound like reasonable names to me.  MTS is used as a
common abbreviation for Microsoft Transaction Server, so you might
want to avoid that.

>     1.  Isn't there a problem in open source with all the programming styles
> possible?  Don't programmers get annoyed, if not confused, having to look at
> so many peoples' codes?

The maintainer has the freedom to reject submissions that do not match
a standard coding style.  If the submission is source to an
independent program, less scrutiny is necessary than if the submission
modifies core functionality of a key program or library.
 
>     2.  In http://www.opensource.org/advocacy/case_for_business.html it
> talks of four ways to succeed as a business using open source.  Number 2,
> "loss leader", is looking attractive to me.  Any comments on this?  What
> does the term mean, etymologically?  Where did that name come from?

It just means that you lead out by giving away a product at a net loss
as a way of enticing customers to purchase profitable products and
services.  For technically sophisticated products like databases and
programming languages, it is nearly impossible to get mind share
without a loss leader strategy, because the time required for a
technically sophisticated person to evaluate a product properly is a
major expense comparable to the actual cost of the software.  Oracle
virtually gives away their database for developer use for this reason.

>     3.  Would my proposed design in shell and utilities be easy to port to
> Linux, or Unix, etc.?  (I'm thinking of starting on Windows.)  How much
> control would I have over other peoples' ports of my code?  Would they
> automatically submit ported code to be combined with the original software
> package?

It is not hard to write non-GUI programs on windows that are highly
portable to other operating systems.  I do it all the time.

There is no good way to force people to submit modifications back to
you - there is a powerful incentive for them to do so, however.  If
they make a modification that is not merged into the main source tree,
they will have to keep making that modification every time they get a
new version, which gets old very quickly.  Their only other
alternative is to create their own fork, which is much too labor
intensive for anyone not basing a commercial venture around it. 


>     4.  That same webpage in question 2 (and probably others) gives some
> positive information about companies with open source business plans, but
> how successful are these success stories?  Sure Linux is used everywhere,
> but how much money does Red Hat actually make?  Isn't it just plain harder
> to make money using an open source business model?

RedHat is now breaking even and will likely be healthy on profitable
for a long time.  Many companies based solely on support services for
100% open source projects have not been so lucky, however.  It
completely depends on the market and necessity for support services
for the type of software you are producing.  There is no question that
open source is not the way to become the next Bill Gates.

I think a healthy business model is to build proprietary extensions to
a core open source framework.  It is possible (and often desirable) to
share source code to proprietary components with your customers
without giving them the right to distribute it to others.  Sun does
this with Solaris and Microsoft does it with Windows.  This allows
them to make emergency modifications and have and insurance policy
against your going out of business without destroying the market for
your extensions.  The federal government does not buy anything serious
without an internal source code license for this very reason.

>     5.  I'm not satisfied with the assurances I've heard about releasing
> important company information to competitors.  I'm worried about this: if
> the software is bad, it won't be beneficial to me or anyone else (in which
> case I don't have to worry about competitors), but if it's good, then the
> competitors will take over and make a better business around it faster than
> I am capable of making.  We talked about this issue years back, but I
> forget what you guys told me.

In the long run, the only way to compete is to produce better products
and services than your direct competitors.  The way to avoid direct
competitors is to create and dominate market niches. If your product
is sufficiently well developed it is *far* more likely that a large
competitor will want to buy you out than develop the same
technological expertise in-house.

You should consider the argument for open standards - large complex
systems cannot interoperate without fully documented interfaces
between components. Even something as proprietary as Windows is only a
success due to widespread adoption of a very complex and heavily
documented API.  The rule is that to become a standard you must
specify, and once you specify you are always open to competition.  The
only other way to become a de facto standard is through monopoly
power.

Based on long hard experience, many customers do everything possible
to keep mission critical systems out of the control of a single
vendor. It is possible to create completely proprietary commercial
components that have open, documented interfaces.  As a customer,
however, I would do everything in my power to avoid becoming dependent
on a component that had no reasonable alternatives from other
vendors.  Unix dominates the real world, mission critical system
market precisely because there are multiple serious alternatives so no
single vendor can exercise monopoly power to the detriment of their
customers.  

C,C++, and Java dominate the programming language market for precisely
the same reason.  Sun has effective control over the Java
specification, but they are not so stupid as to try to monopolize the
market for Java implementations.

>     6.  Right now I'm very attracted to the MozPL (MPL) -- and not just
> because they stole my name. :-)  Is it possible to start out with MPL or GPL
> and then change the licence, and make a proprietary version of my software
> later?  

You can change the license of components that your company is the sole
author of at any time, although your community may feel they have been
mislead to some degree.  Realistically, reasonable people understand
that companies have to make a profit to survive, and welcome any
attempt to be open and interoperable.

> Would I need to change the licences of only those source files
> written by people who agree to the change? 

These are the only licenses you can change.  The others would have to
be re-written to stay under their previous terms, due to the copyright
priveleges of the contributors.

> Would Mark and other OM people
> be agreeable to supporting an MPL-ed project?  

I would be.

> I think I want to do an MPL /
> Loss Leader combination.  I'm thinking of maybe making the shell proprietary
> and most of the original utilities open-source. 

No outsider is going to be motivated to write an open source utility
that requires a proprietary shell unless that shell has already
achieved market dominance.

> (Part of the shell design
> will necessarily be, in effect, MPL-ed, because any interface protocol stuff
> for co-ordinating shell and utility found in an MPL-ed utility must be open
> to all.)  

Open protocol / API standards are a related, but very different issue
than open source code licensing.  You can have fully proprietary
components that interoperate using well specified, open protocols. The
best real world example is the Internet, which is based on hundreds of
such protocols documented in freely available specifications called
RFCs.

> Some of the utilities will have to be proprietary, because they
> include TSF translators (involving the proprietary TF binary file format).
> Or should I make all utilities proprietary and the shell open-source? 

I recommend at least one open source shell implementation with trivial
utilities open source as well.  You could make the open source shell
have a plain vanilla command line user interface and market a
proprietary GUI IDE with a debugger and other advanced features.  The
principle here is not to try to make a profit from every casual user,
but rather from serious customers that need first class functionality
and support and are willing to pay for it.  

If you end up with two or three other companies in the same market,
that is no tragedy.  Small companies with three or four programmers
run circles around monoliths like IBM and Microsoft on a daily basis -
that is why large companies like to buy them out.  Cisco is literally
a conglomeration of hundreds of narrow networking startups that were
acquired and merged with the parent company.  This is a very healthy
process because startups are much better at innovation and large
companies are much more stable for the years after the initial burst
of creativity.  This is desirable because serious customers need to
depend on the availability of and support for mission critical
components for decades. 

- Mark