>From a business perspective, having a published formal specification of CFML is a two-edged sword. The reasons to publish a formal spec are: (1) to allow the possibility of alternate implementations; and, (2) to allow the possibility of "others" to contribute to the evolution of the specification.
The negative to (1) is that you open the door wider to competition (as BlueDragon demonstrates, that door is already open even without a formal spec). The worst-case scenario from a commercial software vendor's perspective is that someone uses the published spec to create an open source implementation that puts you out of business. The negative to (2) is that you lose control of the spec, though I think that Sun has demonstrated a good way to allow outsiders to participate in development of Java specs without losing control of the process. The positives to having a published formal spec is that you remove the stigma of CFML being a proprietary language supported by only a single vendor. For example, there would have been no wailing or gnashing of teeth when Macromedia acquired Allaire, or when the Adobe acquisition of Macromedia was announced, because the future of CFML would no longer be so dependent on a single company. Another positive is that you can more openly allow your customers to contribute to the language specification process. I've made several proposals over the past few years (though not recently) to people fairly high up in Macromedia to move to a more open, formal process for specifying CFML. They're not interested, and that's fine--they need to make decisions based on their own perceived best interests. But, I think their decision to keep CFML closed and proprietary ultimately means CFML will always be a niche technology that probably won't grow in market share much beyond what it has today. On a sort of related note, I'm always puzzled when people who embrace "open" technologies, such as Linux and Java, can also embrace ColdFusion, which a "closed" technology; there seems to be a contradiction here. In fact, this contradiction seems to exist within the ColdFusion development team itself, which relies heavily on open source technology (Axis, JasperReports, iText, various Jakarta projects), but is resistant to opening CFML. It seems to me that if "openness" is a good thing at the operating system and platform levels, then it's also a good thing at the application server level. Or maybe the embrace of Linux and Java is less about "openness" and more about "not Microsoft", in which case there's no contradiction in also embracing ColdFusion. Vince Bonfanti http://blog.newatlanta.com New Atlanta Communications, LLC http://www.newatlanta.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert > Sent: Friday, August 05, 2005 8:44 PM > To: [email protected] > Subject: Re: [CFCDev] WOT: CFML as XML > > On 8/5/05, Joseph Flanigan <[EMAIL PROTECTED]> wrote: > <snip /> > > A much better energy would be asking how to make CF better > business choice. > > I'm interested (as an unaffected bystander) in why you think > CF not having a formal language spec that is available to the > public makes it a poor business choice. This might be better > taken off-list, but I'm definitely interested. I don't know > about you, but I'm buying a language implementation, not a > langauge specification. > > cheers, > barneyb > > -- > Barney Boisvert > [EMAIL PROTECTED] > 360.319.6145 > http://www.barneyb.com/ > > Got Gmail? I have 50 invites. > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
