Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Linux Business

Avoiding Microsoft Lock-ins? 11

bayduv1n asks: "My company relies on WinNT primarily for workstations, file servers, and print servers. In my opinion, Linux based solutions are close to offering a viable alternative. I'm sure that management, however, would like to see mainstream acceptance in the corporate world before considering a migration from the current environment. With the Linux drum beating louder and louder, I would like to make recommendations that would leave our future options *open* and avoid locking into MS technology. I consider a lock-in anything that makes it difficult to migrate. One example of a current lock-in is the macros written for Excel. These would require significant effort to migrate to Staroffice Calc. Implementing MS Metadirectory Service could also be classified as a lock-in. My question is: 'What recommendations can I make now to make it easier to migrate to Linux in a couple of years?'"
This discussion has been archived. No new comments can be posted.

Avoiding Microsoft Lock-ins?

Comments Filter:
  • Some ideas (Score:4, Informative)

    by wrinkledshirt ( 228541 ) on Thursday September 06, 2001 @04:05PM (#2259714) Homepage
    1. If you can help it, try not to fall in love with features that only proprietary companies have. If there's something in MS Word that you want but that no other suite has, begin lobbying the crap out of StarOffice, KOffice, Gnome Office, etc. to get that feature.

    2. Learn Python. It's rapidly becoming Linux's answer to VBA. Since you've already mentioned that you're writing macros for Excel, you might be interested to know that KSpread can be scripted using several different languages too. Go into your macros and figure out how you might go about translating them into a different language.

    3. Learn XML, and figure out how to convert your existing data to and from XML. You can justify this to management easily by saying it's a good safety backup and migration technique just in case something horrible happens. The truth is, if you map out your data properly you could probably dump something from an MS solution and rebuild it using a non-MS solution that has some scripting capabilities.

    4. Come up with five practical (ie: non-MS bashing) reasons why you don't need .NET. Keep them on hand when the obligatory meeting happens exploring the issue. Figure out what makes .NET attractive and come up with counter-proposals for those features.

    5. Learn Samba. At least this way you can integrate different systems and don't need to settle for all your machines being MS-based just because you can't help but have one that's MS-based.

    6. Familiarize yourself with different options starting now. Make it an on-going project for yourself to only work with non-MS products. For instance, bring in a Linux machine and do all your word-processing on WordPerfect8. If they won't let you do it at work, try simulating office procedures at home. You can't expect that your company will want to switch over if you can't yourself. If nothing else, the idea of migration to a non-MS platform will be way more attractive if they believe training won't be a problem, which is why you should get this training out of the way now.

    7. Remember that the sort of manager who's interested in any sort of change is a forward-mover. This means that you won't be of any value to this person if you keep telling them why they can't do something. If they're looking for changes, it means that they think their existing systems are inadequate and they want to upgrade them -- your job is to show them how a Linux (or whatever) solution can be an even better upgrade. Simply telling them that such-and-such a software solution is unsafe or unnecessarily expensive won't work for them. You've got to counter with another suggestion that'll address their reasons for wanting to change in the first place.
  • Recognize cost (Score:3, Interesting)

    by AT ( 21754 ) on Thursday September 06, 2001 @04:33PM (#2259993)
    The best thing to do is to make sure all decisions made regarding infrastructure recognize there is a cost. Specifically, there is a cost to going with any technology that locks in, and there is a risk going with a technology owned by and controlled by a single company.

    By adding this into your decision-making process, you might not meet your personal goal of going linux, but you will make a better business decision.
    • by 4of12 ( 97621 ) on Thursday September 06, 2001 @05:31PM (#2260499) Homepage Journal

      I sympathize with your recommendation. It is absolutely rational and, in theory, should work.

      In practice, however, most corporate IT decision makers live in an MS World, where even the ability to perceive lock-in is severely diminished.

      There are constantly new MS Market Extending products being offered to fix holes in their existing MS all-encompassing fabric. Needless to say, these new products typically introduce further lock-ins in the guise of features. I don't have to tell you how many times I have seen products sold that have a functionality that was either:

      • already in UNIX years ago, or
      • not needed in UNIX because of its better design (virus scanners, anyone?)

      No, I think there are 2 important strategies you should follow, in addition to emphasizing total costs.

      At every opportunity, promote adherence to openly published standards for interfaces between all parts of products in your enterprise.

      Ask about RFCs, about protocols for data exchange, about file formats, about interoperability with competing products, about published APIs and the ability to get to your data ten years from now when you're afraid that Win 2012 won't run OfficeXP because of the upgrade treadmill you've been climbing.

      Secondly, and more importantly, deploy a few Linux boxes as test bed machines for a new, vital service.

      Yes, you can also run a few for various little tasks like print service, file service, web service.

      But what I'm advocating here is you thinking up of what your business could really find useful from a computer. I'm postive that a intelligent sysadmin can see many vital needs, such as for a cheap reliable 3-tier (browser/Apache/PHP/MySQL) web based system that can be used to keep track of <insert dynamic items getting away right now> for your company. After you get it working for a few weeks, show it off to your management and let them point their browser to a dynamic updating portal view of their business. PHBs love that kind of control view.

      You can get yourself kudoes for something you put together in your off-hours with free software and using that cast-off piece-of-junk computer sitting out by the dumpster. They'll be impressed.

      I think the best testimony to the utility of free software in any business situation is an actual working demonstration. When people see it performing a useful, vital function, day-in and day-out, on obsolete hardware, with no big checks to cut for license renewals, it speaks volumes.

      Just do it!

      • Going along with that same idea, make sure that anything you show them is in solid, working condition. Don't get eager and demonstrate a beta-quality product. Make sure that what you show them is something that demonstrates the good points of linux (just like selling anything else).

        I also agree with the slow migration tactic... Start with a few servers (like print servers, etc.) Allow your admins to have time to configure/setup "stuff"... let them get really intimate with linux and grow to understand it. Once you have it in place here and there, migrate the person at the switchboard to linux (they only play solitaire and surf the web anyways), etc.

    • You should consider your motivation here. Your real job should be to help your company make the decision that is best for the company.


      If you think that Linux is close to being an alternative, then you really don't think it's an alternative. Don't waste your company's time and money. Trying to push Linux when you don't think it's a clear win will do nothing but reinforce the image of Linux users as commie zealots that let their playthings get in the way of real business.


      If you do think that Linux is a better choice, figure out why and document it.


      Often, the advantages may lie in places that your bosses may not look. For example, upgrade paths are smoother; you don't have to upgrade every two years. If the advantages you see are in a "blind spot", shine the light on that blind spot.

  • This obviously applies mainly to applicatin development but it is important if you are developing things for use in-house. Microsoft always adds a bit on here and there to all the "standards" they addopt (embrace, extend - you know the deal). Try and find out where the standards stop and where Microsoft's extensions start. For example make sure web applications developed for internal use will run on IE and Mozilla/Konqueror. Use a subset of SQL that is supported by SQL Server, Postgres, Interbase and SAPDB (or make sure you can convert easily from one to another). If it isn't possible to avoid proprietary extensions (or the extensions solve a problem in a way that it would be crazy to ignore them) at least encapsulate them in a single area.
    Another area I've seen lock-in is using windows integrated authentication in ASP applications, which locks you in to using windows clients (I don't think SAMBA overcomes this but I could be wrong). I think the web has great potential for un-shackling people from M$, but so many times I see them tighten the manacles by accepting browser compatability only with IE etc. etc.
  • Create 2 DNS aliases: ldap and imap

    Point these 2 alias at your Exchange server.
    Set up your email client to use IMAP4 for access to the Exchange server email and LDAP to access the Exchange email directory.

    If you use Outlook for scheduling, learn how to publish your free/busy times to a URL and how to configure Outlook to check a URL for free/busy information.

    After you finish all of this scratch your head and ask yourself why you are using Exchange Server.

    And then ask yourself why Microsoft chose to require Outlook to have a set of local folders (local .pst file) when used with IMAP.
  • The solution is a simple one - how do you work with the goal of migrating to Linux?

    Don't.

    Work with the goal of being flexible enough to move in any direction. Don't use proprietary solutions - use open standards. If you use Word in house, make RTF of similar the standard format. Access databases via SQL instead of directly. Never select a product simply because the rest of your products are from the same vendor. Never make a product which may go away, or be "demarketed" in favor of a different product part of your environmet.

    Selling these ideas to your employer require work, and some are more difficult to implement up front. Your task is to prove that there are equal or superior options open to you now, and to demonstrate that it is likely to save your employer money.

Byte your tongue.

Working...