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