Why do you crave single-vendor control?
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
In my experience, most developers love to play around with lots of different technologies and compare competing products and vendors. It's usually management that has the fear. The old "nobody is fired for buying IBM" because it was so standard, which today is "nobody is fired for buying Microsoft". Those Developers that do like vendor lock-in are usually more interested in if the technology works with their tools of choice (ie Visual Studio) rather than the vendor themselves I think, but again, this is all just from personal experience.
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
There is a theory that goes a little like this: Having fewer vendors translates into fewer configurations needed… That coupled with the idea that it is hard work to compare different vendors, and the ‘No one got fired for choosing IBM syndrome’ and you get an understanding of a majority of the decisions. Being a Microsoft (or choose your favorite large vendor) shop seals the deal.
Belief in God Finding Allah Surah AlHaaqa(The Reality) Surah Qaf
-
In my experience, most developers love to play around with lots of different technologies and compare competing products and vendors. It's usually management that has the fear. The old "nobody is fired for buying IBM" because it was so standard, which today is "nobody is fired for buying Microsoft". Those Developers that do like vendor lock-in are usually more interested in if the technology works with their tools of choice (ie Visual Studio) rather than the vendor themselves I think, but again, this is all just from personal experience.
They also like to pick what they know. We use DevExpress which for me comes with a lot of annoyances and bugs (they probably consider them features) which have taken me time to learn and work around. Should I jump to another UI toolkit? Will it not have any annoyances or bugs (unlikely)? Would I rather stick with what I know and not have to relearn another toolkit just so I can get er done? Yes. Would I enjoy learning a new toolkit that's based on a different paradigm (WPF) and for solving different solutions? Yes. In other words, once I've leared a tool that solves a specific problem I'm not overly joyed at learning a new tool to solve the same problem unless it provides an order of magnitued ROI. The vendor doesn't matter as much as the tool + problem domain.
Todd Smith
-
They also like to pick what they know. We use DevExpress which for me comes with a lot of annoyances and bugs (they probably consider them features) which have taken me time to learn and work around. Should I jump to another UI toolkit? Will it not have any annoyances or bugs (unlikely)? Would I rather stick with what I know and not have to relearn another toolkit just so I can get er done? Yes. Would I enjoy learning a new toolkit that's based on a different paradigm (WPF) and for solving different solutions? Yes. In other words, once I've leared a tool that solves a specific problem I'm not overly joyed at learning a new tool to solve the same problem unless it provides an order of magnitued ROI. The vendor doesn't matter as much as the tool + problem domain.
Todd Smith
Good point. If you really like one solution you tend to try to play favorites with it too, even if others are comparable. For better or worse, few types of workers get as religious about their tools as programmers! ;P
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
i think the default assumption is that stuff from one vendor will play nicely with other stuff from that same vendor, regardless of horror stories about .doc files on different platforms - crossing platforms isn't something i do much of, as a developer. but, it's not overwhelming - i happily use gSoap and openSSL in my MFC desktop apps because i hate dealing with MSXML's COM and versioning issues.
image processing toolkits | batch image processing | blogging
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
Off the top of my head: Cost. Generally vendors will offer you better terms if you agree to license more of their products over a longer term. Interoperability is also a valid reason. The example you quote is focused mainly on web platforms, but with server software having a 'one-size fits all' to product interoperation is a significant plus. For example, Microsoft's System Center[^] products may not be easy to set up, but you won't have problems where an interface changes and suddenly system A can't talk to system B anymore. Support is also important, although not always from the vendor. For example, you know if Exchange Server goes down with some obscure error and an even more obscure MSKB article describing it, then there will be at least a dozen expert bloggers out there who have covered the problem in detail. If that doesn't work then at least you know reasonably qualified help is only an expensive phone call away. The reasons are pretty much the same for hardware vendor lockin as well. The problems are, of course, you are at the mercy of the vendor you choose.
Ðavid Wulff What kind of music should programmers listen to?
Join the Code Project Last.fm group | dwulff
I'm so gangsta I eat cereal without the milk -
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
Shog9 wrote:
when does a single-vendor toolset become an overwhelmingly positive factor for you, and why?
It doesn't. Ever. Within a single vendor, products don't play nice. Even upgrades often don't play nice with the earlier version. I mix and match tools that fit my needs. I avoid single vendor solutions because when one thing gets updated, it often breaks something else I'm dependent upon. I look for multi-vendor solutions to avoid tight coupling of tools and to broaden the range of selection that I have for a particular need. I also prefer individual components vs. component libraries because I'm not into the hidden, bloated, complex architectural mindset that you implicitly buy into. Yes, there's something to be said for a consistent set of properties across all components, but frankly, I don't see that from single vendor components! A property that's in one control is in another but expressed completely differently! The behavior can be different too! In other words, the days of idealism have been replaced with the cynicism of "I assume your marketing dept and website is bullshitting me and it doesn't actually work nearly as well as advertised". Oh sure, it might work as advertised for the simple turnkey examples they provide, but never when you really get down to the "here's what I need to do" work. Marc
People are just notoriously impossible. --DavidCrow
There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer
People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith -
Off the top of my head: Cost. Generally vendors will offer you better terms if you agree to license more of their products over a longer term. Interoperability is also a valid reason. The example you quote is focused mainly on web platforms, but with server software having a 'one-size fits all' to product interoperation is a significant plus. For example, Microsoft's System Center[^] products may not be easy to set up, but you won't have problems where an interface changes and suddenly system A can't talk to system B anymore. Support is also important, although not always from the vendor. For example, you know if Exchange Server goes down with some obscure error and an even more obscure MSKB article describing it, then there will be at least a dozen expert bloggers out there who have covered the problem in detail. If that doesn't work then at least you know reasonably qualified help is only an expensive phone call away. The reasons are pretty much the same for hardware vendor lockin as well. The problems are, of course, you are at the mercy of the vendor you choose.
Ðavid Wulff What kind of music should programmers listen to?
Join the Code Project Last.fm group | dwulff
I'm so gangsta I eat cereal without the milkDavid Wulff wrote:
Interoperability is also a valid reason. The example you quote is focused mainly on web platforms, but with [single-source server software] you won't have problems where an interface changes and suddenly system A can't talk to system B anymore.
Well, of course that's the reason given for going single-vendor on Web platforms as well. ActiveX (browser controls), DCOM, Java, Flash, and now WPF/E are all being promoted under that flag - if you use our system, we control both the client and the server side of things, so it'll always just work. Of course, sometimes the picture isn't quite as rosy as it's painted in the ad copy. ;) Now, i'm not much of an IT guy (which is one reason why i'm asking these questions), and really don't know much about what System Center is, or what it's used for (other than that it's the Best Choice for Windows, a Foundation for Growth, and that it'll Fuel Productivity and Manage Strength :rolleyes: ). Obviously, the promise of painless integration is quite a draw... in your experience, has it actually worked out to be a net gain? That is, is the (hopefully) one-time cost of setup and deployment offset by a quantifiable reduction in the time and effort spent on future maintenance?
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
I use Dreamweaver for css and html/xhtml javascript, VS IDE for C#, Eclipse for Java, Toad for oracle (and sql developer, and Enterprise Edition for SQL Server. Dedicated tools are usually better than integrated. Oh, and I use the VSS Interface for all my source control work but prefer CVS when I get a chance.
File Not Found
-
David Wulff wrote:
Interoperability is also a valid reason. The example you quote is focused mainly on web platforms, but with [single-source server software] you won't have problems where an interface changes and suddenly system A can't talk to system B anymore.
Well, of course that's the reason given for going single-vendor on Web platforms as well. ActiveX (browser controls), DCOM, Java, Flash, and now WPF/E are all being promoted under that flag - if you use our system, we control both the client and the server side of things, so it'll always just work. Of course, sometimes the picture isn't quite as rosy as it's painted in the ad copy. ;) Now, i'm not much of an IT guy (which is one reason why i'm asking these questions), and really don't know much about what System Center is, or what it's used for (other than that it's the Best Choice for Windows, a Foundation for Growth, and that it'll Fuel Productivity and Manage Strength :rolleyes: ). Obviously, the promise of painless integration is quite a draw... in your experience, has it actually worked out to be a net gain? That is, is the (hopefully) one-time cost of setup and deployment offset by a quantifiable reduction in the time and effort spent on future maintenance?
----
...the wind blows over it and it is gone, and its place remembers it no more...
Shog9 wrote:
other than that it's the Best Choice for Windows, a Foundation for Growth, and that it'll Fuel Productivity and Manage Strength
See, you do know what it is! And you didn't have to sit through three hours of badly dubbed sales videos. ;P
Shog9 wrote:
the promise of painless integration is quite a draw... in your experience, has it actually worked out to be a net gain? That is, is the (hopefully) one-time cost of setup and deployment offset by a quantifiable reduction in the time and effort spent on future maintenance?
Over the last three odd years I've been involved in selling the systems and building software that runs on them, not maintaining them past the handover date (all of these companies have their own in-house technicians). I mainly work with them in sandboxes, regularly breaking and mending them as seems typical in our line of work. The exception to that has been DPM 2006 which we use here and it is just amazing at what it does -- I am positively thrilled at the thought of v2. :-O What has been fed back though has been largely very positive. We've only seen good things after migrations from convoluted Unix/IBM/Solaris/and other enterprisey platforms to Microsoft solutions. However, ask me again in a year and it may be different. We are currently working with clients rolling out some of the new Office Servers, and those aren't as easy to cost past the deployment.
Ðavid Wulff What kind of music should programmers listen to?
Join the Code Project Last.fm group | dwulff
I'm so gangsta I eat cereal without the milk -
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
Support responsibility. Rollout of DSL worked like a charm over here in Germany, and I was surprised to hear about other countries to claim it's utter crap, never working, and a total ripoff. The difference: DSL was rolled out by a state monopoly here. "Over there" if something was not working, the DSL provider blamed the phone company or the ISP, the ISP blamed phone and DSL providers - the last part of this sentence is left as an exercise to the reader. That was my impression watching DSL discussions, I have no numbers to back it up. For me: Anything that is not crucial for my job just has to work. I don't want explanations, but I want the stuff up and running. Not having to haggle with them who of aour suppliers is responsible is a boon. Anything that is crucial, that gives my product an edge over competitors, I want to control completely. At least, then it's my fault.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Support responsibility. Rollout of DSL worked like a charm over here in Germany, and I was surprised to hear about other countries to claim it's utter crap, never working, and a total ripoff. The difference: DSL was rolled out by a state monopoly here. "Over there" if something was not working, the DSL provider blamed the phone company or the ISP, the ISP blamed phone and DSL providers - the last part of this sentence is left as an exercise to the reader. That was my impression watching DSL discussions, I have no numbers to back it up. For me: Anything that is not crucial for my job just has to work. I don't want explanations, but I want the stuff up and running. Not having to haggle with them who of aour suppliers is responsible is a boon. Anything that is crucial, that gives my product an edge over competitors, I want to control completely. At least, then it's my fault.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!:-D Sounds like a nice German thing then. Over here state regulated monopolies are notorious for playing the blame game even amongst their own departments. Can't tell you how many times, when working in the southern US, I called Bell South and was redirected ten times within the same company eventually making a full circle and tearing out my hair! :mad:
-
:-D Sounds like a nice German thing then. Over here state regulated monopolies are notorious for playing the blame game even amongst their own departments. Can't tell you how many times, when working in the southern US, I called Bell South and was redirected ten times within the same company eventually making a full circle and tearing out my hair! :mad:
On the downside, you were dealing with a monopoly with no amount of flexibility, service was slow and could be infuriating. After opening up the market, both prices and service quality plummeted.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us! -
Off the top of my head: Cost. Generally vendors will offer you better terms if you agree to license more of their products over a longer term. Interoperability is also a valid reason. The example you quote is focused mainly on web platforms, but with server software having a 'one-size fits all' to product interoperation is a significant plus. For example, Microsoft's System Center[^] products may not be easy to set up, but you won't have problems where an interface changes and suddenly system A can't talk to system B anymore. Support is also important, although not always from the vendor. For example, you know if Exchange Server goes down with some obscure error and an even more obscure MSKB article describing it, then there will be at least a dozen expert bloggers out there who have covered the problem in detail. If that doesn't work then at least you know reasonably qualified help is only an expensive phone call away. The reasons are pretty much the same for hardware vendor lockin as well. The problems are, of course, you are at the mercy of the vendor you choose.
Ðavid Wulff What kind of music should programmers listen to?
Join the Code Project Last.fm group | dwulff
I'm so gangsta I eat cereal without the milkDavid Wulff wrote:
but you won't have problems where an interface changes and suddenly system A can't talk to system B anymore.
David Wulff wrote:
then there will be at least a dozen expert bloggers out there who have covered the problem in detail.
Hmm, I am not sure those are "single vendor" only features. We developed our entire Java system with OC4J and recently switched to JBOSS. It all worked. We can go to BEA, use their app server and it will more than likely work too. And if it didn't work with the latest version I could look back in the versioning and find one that does. In ten years I'll bet there is a bigger chance I can get today's version of JBOSS than today's version of Exchange or .NET Framework. JBOSS will be on someone's server somewhere with no vendor hunting it down and killing it unlike install files for Exchange (less so a problem for .NET Framework but it doesn't have the same "Hey everybody, take these files and host them however you want for as long as you want.") I can't get the source for .NET Framework now either, or in the foreseeable future. I can get the source for any of the systems we are using and compile to work on our distribution (and we do this for some significant performance, size and simplicity gains.) As for support you get drowned with Apache/Java/JBOSS/OC4J/Rails/PHP etc. support from professional companies to bloggers in their basement. And we switched to JBOSS exactly because we felt OC4J was taking too much control from us, we didn't want to be at its mercy. And our code worked in it. I fully admit it is messier than single-vendor systems but there is so much support and experience out there we've never had a serious problem. The Windows world was very pretty when I was inside it and the rest seemed dirty as fek. But things have changed.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
I was reading "The Open Web and Its Adversaries", an essay on the threats posed by things like Flash and WPF/E. And i ran across this paragraph, which i find even more interesting out of context:
Dare Obasanjo argues that developers crave single-vendor control because it yields interoperation and compatibility, even forced single-version support. Yet this is obviously not the case for anyone who has wasted time getting a moderately complex .ppt or .doc file working on both Mac and Windows. It's true for some Adobe and Microsoft products, but not all, so something else is going on. And HTML, CSS, DOM and JS interoperation is better over time, not worse. TCP/IP, NFS, and SMB interoperation is great by now. The assertion fails, and the question becomes: why are some single-vendor solutions more attractive to some developers?
So i'm repeating that question to you folks, in the context of the work you do and the tools you use: when does a single-vendor toolset become an overwhelmingly positive factor for you, and why? Examples:
- VS2005 + Team System (vs. separate source control, testing, etc.)
- Source Control + Bug Tracking from the same vendor (several companies are offering these now)
- Component Libraries vs. individual components (i'm staring at an ad for Dunas' "Dashboard Bundle" right now, but there are scores of these in all sorts of categories).
----
...the wind blows over it and it is gone, and its place remembers it no more...
Shog9 wrote:
when does a single-vendor toolset become an overwhelmingly positive factor for you, and why?
When your local hiring pool is filled with people who only know that vendor. That is about the only situation I can think of. We use a range of vendors and are pretty happy with the situation.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
On the downside, you were dealing with a monopoly with no amount of flexibility, service was slow and could be infuriating. After opening up the market, both prices and service quality plummeted.
Developers, Developers, Developers, Developers, Developers, Developers, Velopers, Develprs, Developers!
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
Linkify!|Fold With Us!It's been a little while since I had to deal personally with any US telecoms (thankfully!) but I think it's a stretch to say the market has opened up, especially for baby bell Bell South. If you mean AT&T vs. Bell South, then I would agree with that statement. On the developer platform side of the world, however, there isn't nearly the kind of government interference yet, and I personally like having variety and competition. Sometimes its nice to be the big fish in the smaller pond, for instance, and service goes dramatically up. But then, my thinking tends to lean a lot closer to Marc and Ennis, where I don't like tools that require tight coupling but prefer to have a more modular setup. Good for coding and good for tools for the same reasons - at least for my style.
-
David Wulff wrote:
but you won't have problems where an interface changes and suddenly system A can't talk to system B anymore.
David Wulff wrote:
then there will be at least a dozen expert bloggers out there who have covered the problem in detail.
Hmm, I am not sure those are "single vendor" only features. We developed our entire Java system with OC4J and recently switched to JBOSS. It all worked. We can go to BEA, use their app server and it will more than likely work too. And if it didn't work with the latest version I could look back in the versioning and find one that does. In ten years I'll bet there is a bigger chance I can get today's version of JBOSS than today's version of Exchange or .NET Framework. JBOSS will be on someone's server somewhere with no vendor hunting it down and killing it unlike install files for Exchange (less so a problem for .NET Framework but it doesn't have the same "Hey everybody, take these files and host them however you want for as long as you want.") I can't get the source for .NET Framework now either, or in the foreseeable future. I can get the source for any of the systems we are using and compile to work on our distribution (and we do this for some significant performance, size and simplicity gains.) As for support you get drowned with Apache/Java/JBOSS/OC4J/Rails/PHP etc. support from professional companies to bloggers in their basement. And we switched to JBOSS exactly because we felt OC4J was taking too much control from us, we didn't want to be at its mercy. And our code worked in it. I fully admit it is messier than single-vendor systems but there is so much support and experience out there we've never had a serious problem. The Windows world was very pretty when I was inside it and the rest seemed dirty as fek. But things have changed.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
Paul Watson wrote:
The Windows world was very pretty when I was inside it and the rest seemed dirty as fek.
I've gotta say, i really admire your ability to see beauty in whatever area you happen to be. It's practically a super-power. You could be "Cap'n Paul"... oh, right.
----
...the wind blows over it and it is gone, and its place remembers it no more...
-
Paul Watson wrote:
The Windows world was very pretty when I was inside it and the rest seemed dirty as fek.
I've gotta say, i really admire your ability to see beauty in whatever area you happen to be. It's practically a super-power. You could be "Cap'n Paul"... oh, right.
----
...the wind blows over it and it is gone, and its place remembers it no more...
hehe. Hey, something else "single vendor" is good for; perks. I got flown to Vegas, flown to the Grand Canyon, had free pizza, fun conferences, free drinks, was shown around cool offices, access to betas nobody else in the area had and so on by Microsoft. Sticking to one vendor lets you focus on them and they then give you perks. You don't get as many perks by using multiple vendors, you just don't build up the "relationship." So, if you want free booze, use a single vendor. Otherwise, use multiple vendors. (Of course if you work for a company that a vendor would love to have even on just one product, they'll give you free booze just for downloading their 14 day free trial. But hey, who wants to work for one of those companies eh?)
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...
-
hehe. Hey, something else "single vendor" is good for; perks. I got flown to Vegas, flown to the Grand Canyon, had free pizza, fun conferences, free drinks, was shown around cool offices, access to betas nobody else in the area had and so on by Microsoft. Sticking to one vendor lets you focus on them and they then give you perks. You don't get as many perks by using multiple vendors, you just don't build up the "relationship." So, if you want free booze, use a single vendor. Otherwise, use multiple vendors. (Of course if you work for a company that a vendor would love to have even on just one product, they'll give you free booze just for downloading their 14 day free trial. But hey, who wants to work for one of those companies eh?)
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
And with that, Paul closed his browser, sipped his herbal tea, fixed the flower in his hair, and smiled brightly at the multitude of cute, furry animals flocking around the grassy hillside where he sat coding Ruby on his Mac...