[om-list] Re: MTShell and 4C

Wed Oct 3 08:26:14 EDT 2001

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
> 
> 
> 