[om-list] Re: MTShell and 4C

Wed Oct 3 21:15:11 EDT 2001

I don't think I did--you could check the archive--it's linked off our 
web page but I don't see it there or remember (could be wrong)....

Tom and other Packers wrote:

> Thanks, Luke and Lee
> 
>     I'll think more about all this.  And I will draw up submission
> conventions sometime.  I expect to get serious about this project in
> mid-February, 2002.
> 
>     Luke, I sent the original list of questions to the om list address, and
> apparently you and Mark and Lee did not get it -- or did you get two copies
> of my original "MTShall and 4C" letter?
> 
> tomp
> 
> ----- Original Message -----
> From: "Luke Call" <lacall at onemodel.org>
> To: "One Model List" <om-list at onemodel.org>
> Cc: "Lee Howard" <redder at deanox.com>
> Sent: Wednesday, October 03, 2001 6:26 AM
> Subject: Re: [om-list] Re: MTShell and 4C
> 
> 
> Mark and Lee have done a good job commenting on this. There are other
> discussions of open source-related business models at
> http://tuxedo.org/~esr/writings/magic-cauldron/ (it's a long but very
> interesting read). One model you may have already looked at is used
> ghostscript (if I remember right) where they sell the current version
> w/o source, and opensource all prior versions.
> 
> One drawback (or benefit, some would say) of MPL is that (if I
> understand right) no one can link GPL code with MPL code. The FSF
> perspective on this is discussed in detail at
> http://www.fsf.org/licenses/licenses.html, and their view on other
> licenses including MPL is at http://www.fsf.org/licenses/license-list.html.
> 
> Was there a problem w/ the om-list?
> 
> Luke
> 
> Tom and other Packers wrote:
> 
> 
>>Mark
>>
>>    Did we figure out what went wrong with the list?  (Ben, the address
>>
> for
> 
>>the OM-list is om-list at onemodel.org.)
>>
>>    There just aren't enough initial-letters to go around in this
>>acronym-happy community.  :-)
>>
>>    Thanks for all the feedback.  This is very helpful, and very
>>interesting.
>>
>>    I think I will do what you say, including making the first simple
>>
> shell
> 
>>open-source.
>>
>>tomp
>>
>>----- Original Message -----
>>From: "Mark Butler" <butlerm at middle.net>
>>To: "Tom and other Packers" <TomP at burgoyne.com>
>>Cc: "One Model List" <om-list at onemodel.org>; "Luke Call"
>><lacall at onemodel.org>; "Lee Howard" <redder at deanox.com>
>>Sent: Tuesday, October 02, 2001 9:55 AM
>>Subject: Re: MTShell and 4C
>>
>>
>>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
>>
>>
>>
>>_______________________________________________
>>om-list mailing list
>>om-list at onemodel.org
>>http://www.pairlist.net/mailman/listinfo/om-list
>>
>>
>>
>>
> 
> 
> 
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
> 
> 
> 
> _______________________________________________
> om-list mailing list
> om-list at onemodel.org
> http://www.pairlist.net/mailman/listinfo/om-list
> 
> 
> 