From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,afb4d45672b1e262 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad01.newshosting.com!newshosting.com!208.49.83.154.MISMATCH!atl-c08.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!KNOLOGY.NET-a2kHrUvQQWlmc!not-for-mail Date: Tue, 11 Apr 2006 08:54:48 -0500 From: "Marc A. Criley" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Making money on open source, if not by selling _support_, then how? References: <7NOdne-iYtWmIafZnZ2dnUVZ_tWdnZ2d@megapath.net> In-Reply-To: <7NOdne-iYtWmIafZnZ2dnUVZ_tWdnZ2d@megapath.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <292bf$443bb4e4$45491254$20549@KNOLOGY.NET> X-Complaints-To: abuse@usenetserver.com Organization: UseNetServer.com X-Trace: 292bf443bb4e4e0ecb7f120549 Xref: g2news1.google.com comp.lang.ada:3771 Date: 2006-04-11T08:54:48-05:00 List-Id: This seems like an interesting tangent off the "Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?" topic, so let's branch off... :-) Randy Brukardt wrote: > This discussion highlights one of problems (maybe the only real problem) > with the typical open source model. It relies on selling support to generate > the revenues needed to support the development. (Developers need to eat!) > But truly great software does not need support at all (no bugs, intuitive to > use, etc.), and probably requires little training. (I consider a support > call an indication of failure.) I basically agree with Randy here. If the software is truly great, as he defines it (no bugs, intuitive to use, and I would add acceptable performance), then the need for "traditional" support to report bugs and find out how to work around them is gone, and if one knowledgeable in the application domain finds the software intuitive to use, then again the need for support to figure out how to do something is gone. So how does the developer of a potentially great open source (or even proprietary) product justify the need for a customer to buy support from the developer? One area is providing support for the problem domain, not just the product, i.e. consulting. AdaCore does this, and I expect RR does as well for their customers. While the expert in the problem domain may find the product intuitive and not need support, most product's users are not experts, and will find themselves looking for help in solving their problem with the aid of your product, where your (the developer's) expertise becomes valuable. If your product is capable of assisting the customer is solving their problem in your product's application domain, then it's reasonably likely you have a good structural understanding of that domain. (This also depends on the complexity of the problem domain, you probably won't find much need for support in the domain of cutting 2x4s to length, but will in distributed, fault-tolerant applications.) Another area for support isn't so much "support" as it is maintenance and upgrades. This of course runs the risk of adding features of marginal value, just so you can say the software is now "better" and more capable. Creeping featurism is a well-known issue in this industry, and most people know what can result from that--just look at the mature products of a certain large productivity applications and operating system company. Another variant of this can almost be viewed as "changing things for the sake of changing them." If you've ever installed an upgrade of a product and remarked that some feature you've always used now works, or is accessed, differently and that "it was perfectly fine the way it was", then you know what I'm talking about. Once a program is saturated with the necessary features, and they work well together and operate efficiently, i.e., the software is "great", there's no justification for changing them or adding more, and therefore there's no justification for software support on that basis. So if your software is great, and is well- and thoughtfully featured, and you want to keep developing software, what can you actually do to your product to justify customer support? What I've seen, and been involved in, both in my professional career and in my own personal activities, is that often the software can be the basis of a "family" of products. Instead of increasing the "density" of features by adding or changing them, increase the breadth of applicability. E.g., if your programming tool only handles Ada, add support for C++ and Java; if your command and control system does launch planning for a specific type of missile, add support for other kinds, and then other types of weapons; if your text processor handles well-structured, but non-standardized text formats, add explicit support for XML. This can of course get out of hand ("when all you have is a hammer, every problem looks like a nail"), but if you were capable of writing great software (in all the aspects of "greatness") in the first place, you ought to be able to tell what problems domains it makes sense to expand your software's functional breadth into. > So, it appears that open source (at least > the traditional model) is incompatible with truly great software. Ehn, okay, maybe with the "traditional model", but that's a very narrow support model. -- Marc A. Criley -- McKae Technologies -- www.mckae.com -- DTraq - XPath In Ada - XML EZ Out