WS-RandomThoughts
while we've been in comm with a couple big software vendors (Sterling Commerce and webMethods), I thought it was pretty funny that both of them seemed to scoff at the notion of us exploring open source alternative s to their software. guess what guys....the granted value of an open source solution doesn't have to be as high as yours because the cost is minimal. since we've been able to put one of them into near panic-attacks over losing our business, and gotten the other to chop more than 50% off of their price, I feel like I've injured their normal proprietary model enough that it's okay to now go ahead and buy their software, and then make the open-source version of it on my own in a couple years.
somewhat related to that last comment...I think I have a better understanding, angle, and appreciation for the 'sugar-daddy' open-source approach, and perhaps a specific option of positioning lamp5 that way. I'm considering a company like EDS or CA...a software consulting services firm. I initially thought that Lumata or lamp5 would become one, but there would be no harm in having lamp5 join with one, as long as it could be convinced and accept the open source model, as follows:
let's suppose that lamp5 goes thru the normal open-source startup process (which I'm hoping is underway) in which a few dedicated developers get interested in scratching a common itch and leaving the solution out in the public eye. so work progresses, but pretty slowly...hopefully the pace will increase as more developers come on.
eventually there's a structuring time where official project leads are established, a company charter could be drawn, developers are recruited and organized, some contracts and revenue crops up. after some pioneering businesses implement, the solutions gets a bit of professionalism to it, and can attract the interest of a sugar-daddy.
enter EDS.
EDS sells consulting services, so they're not in the software-selling business, or if they are, it's minimal in comparison. but, EDS doesn't need to get themselves far into the software-selling business to capture benefit from an open-source platform like lamp5. while EDS indirectly contributes to MySQL by consulting with Sabre for their large MySQL system, which involves many commercial license purchases, EDS could more direclty support an open-source project and still remain a consulting firm.
if EDS sees that lamp5 has a small, but successful track record, it might be interested in doing a test case with it. if they find benefits of implementing solutions using lamp5, they could be interested in helping lamp5 progress, to enhance the solutions they're able to offer using it. at this point, open-source both shines, and creates havoc, for the creators.
if the creators are still on top of the game, and are committed to enhancing lamp5 on their own, EDS will likely hire on the lamp5 creators/developers/company to build lamp5 in the direction EDS dictates. if the original lamp5 creators are slacking off, EDS may have their own people usurp the leadership of lamp5, or could turn lamp5 into a different product that they choose. such is the nature of open-source.
lamp5 itself is just the tool EDS uses to get their business done. if they are the sole funders of the tool's development, they can control how the development of the tool progresses. even though other entities will have full access to the tool, their control over it helps them to establish both their methodology and leadership in the market.
it takes a gutsy move by a large firm to play sugar-daddy to open-source software, but it's being done fairly successfully, and lamp5 need be no different. now, if anyone has an idea of a good candidate for lamp5's sugar-daddy...please let me know.
</div>
MSN search uses Linux
"A Microsoft spokesman argued that it would be 'inflammatory and unfair' to say that the thing leverages Linux."
I wonder how long it will be before Microsoft finally adopts a Linux-friendly stance...since they're starting to get clobbered all over the server market.
</div>
good followup
standards bodies, no, mapping standard, yes
one of the major areas of the IT landscape that web services will be applied to is in business-to-business e-commerce, b2b. in contrast to b2c (business-to-consumer) e-com, where a business is presenting its information (catalogs, prices, etc) straight to customer, ie, thru a website, b2b commerce usually deals with computer/information systems of one company transmitting information directly to another. like sending purchase orders, invoices, etc.
traditionally, b2b e-com has been done thru EDI (electronic data interchange) and it's very expensive, usually the EDI providers charge on a per-byte basis. but since web services could do the same thing over a regular http protocol, all they need is an internet connection and they're ready for b2b.
now even if businesses are able to communicate with each other over the internet, they have to establish a common language, or format, for their messages. so they both agree what a purchase order looks like. up come the various standards bodies like ebXML, cXML, UBL, and industry standards like CIDX. all of these 'languages' do things differently, and overlap with each other in various locations. all of these formats were also developed by the giants in the market to fit their standard ways of doing business.
if you are a small business and you want to participate in the great Web Services/XML/Internet ecommerce bazaar, currently, you're forced to contort your own ways of doing business so that it is conducive to communication with others'. but that's what latching onto these standards would imply for small businesses. and they just don't have that kind of money to invest in a complex IT system to do it. the return, especially now in web services' infancy, is far to small.
I would argue that there needs to be, instead of, or in addition to, XML standards and standards bodies, another XML standard language which is used to describe the mapping of one XML format into another. if we, as a small biz, had a standard way to present our own format's translation into another, we would only ever have to create that translation once, and then make it publicly accessible to allow all users of the other format to easily translate into ours.
I had this idea because I've seen many 'data-mapping' products for mapping one xml format into another. when I considered what would be involved in creating one of those programs, I saw that a mapping file is really just another piece of data itself, albeit meta-data concerning two other pieces of data. if we standardized the way xml formats are described to each other, it should make XSLT programming a breeze, and allow better mapping products that could all use a standardized engine for their mappings.
it's not quite a SOAP-box, but it's something I've been mulling over. now it's one the record. </div>
215
"Maybe one problem Open Source developers have with Web Services is that the code responsible for actually implementing a service is rarely on the machine requesting it. This separation of code and functionality greatly reduces the incentive to look at the underlying source code. Worse still, there is no Open Source license (like the GPL or BSD license) that adequately covers Web Services."
open source programmers do tend to keep the pretense that if you need/want to interact with a program in a proper/correct way, you should write to interface with the source code. this kind of interface is exactly opposite the entire concept of web services - connecting and integrating disperate systems with no knowledge of the underlying architecture.
one significant challenge I've had is discovering the synergistic benefits of creating web services on an open-source platform vs. a proprietary platform. the conclusion that I'm starting to draw is that there really is no synergistic benefit, because the nature of web services is such that, as I said, it renders the choice of underlying architecture or programming language a moot point of discussion.
the benefits to be had, then, are just the benefits of the two seperate technologies, realized simultaneously. in creating a service-oriented-enterprise, you capture the benefits of streamlining business processes, sustaining data integrity, and all the other good stuff. in creating open-source software, you get cheap software, solid architecture, and complete control. in implementing open-source web services, you get all of the above.
if you were applying custom-built integration systems with in-house resources, a proprietary platform like J2EE or .NET may very well be the way to go, if you have lots of those resources already. it may be possible to teach a bunch of C# programmers how to make a PHP web service system, but the only benefit you would get is the open-source benefits, which you're already not capturing to their fullest since you're dependent on .NET for systems anyway.
I think what's more important for lamp5 to recognize is not so much the technical synergistic benefits, but more, finding the correct consumer of the total benefits - ie, small-to-medium businesses with small IT budgets that want to be able to "play with the big boys". that's the angle I'm going to take, and hopefully execute on. </div>
