Wednesday, July 01, 2009

Microsoft, Open Source, Barriers to Entry/Barriers to Deploy

Microsoft, Open Source

I had to make a concious decision to have the above title have a comma between Microsoft and Open Source. Putting something like 'and' or 'versus' or 'with' may set the wrong stage for the intent of this blog.


  • Barriers to Entry for a development environment
  • Barriers to Deploy a solution

Traditionally, 'open source' is associated directly with programming languages, with the two more prominent (not only, just prominent) ones being Perl and Java.

So what makes them successful? A number of things do, but I wanted to mention two, from a business and adoption standpoint, key drivers -- Barriers to Entry and Barriers to Deploy.

Rather than have a lengthy paragraph, just going to bullet/summerize (BE = Barrier to Entry removed, BD = Barrier to Deploy removed):

  • BE: You can get perl language for free.
  • BE: You can get various IDE's to use perl for free...or use notepad/vi.
  • BE: Large number of commercial books out there for Perl.
  • BE: Large number of free articles out there for Perl.
  • BE, BD: CPAN, a large centralized repository of code you can use, learn from, and deploy at will for free. A lot of problems, but obvious and obscure, have already been solved and are free for you to use and/or modify.
  • BE, BD: Interpreted, can make changes on-the-fly and immediately see the results (good for learning and prototyping and fast support, questionable for enterprise apps).
  • BD: Multi-OS environment support (with availability of free OS as deployment environment).
  • BE: You can get a java compiler and java VM without cost. Also, several options of compilers and VM's.
  • BE: Eclipse/Netbeans IDE are free.
  • BE: Large number of commercial books out there for Java.
  • BE: Large number of college courses and training classes for Java (varying level of quality however).
  • BE: Large number of free articles out there for Java, with code examples.
  • BE, BD: Several tested/documented solution paths and design patterns for more complex solutions (OSGi, Spring, JavaEE).
  • BE, BD: Many repositories of code and binaries available, free to use and modify -- sourceforge, codehaus,, as well as Maven library repositories.
  • BE, BD: Free to use and deploy build systems (ant, Maven) that are not tied to an IDE, and allows anyone to 'check out or download' code and just start working with it.
  • BD: Multi-OS environment support (with availability of free OS as deployment environment).
  • BD: Java has several servers (JavaEE container servers - Tomcat, Jetty, Jboss, Jonas, Glassfish, Geronimo, etc) that are also free to develop and deploy on.
  • BE,BD: The JCP and/or common solutions usually have competition that continues innovation, and gives developers choices depending on the scenarios presented to them.

  • BE: Large number of commerical books on Microsoft .NET programming language platforms.
  • BE: Large number of college and training courses (relatively stable quality).
  • BE: Various programming language options for the .NET platform.
  • BE: Commerical MSDN access as a repository of solutions, code examples, etc.
  • BE,BD: Graphical/UI builds through the singular, commericial (which is both good and bad, as it's a constant) IDE - Visual Studio.
  • BD: You know exactly where it is going to deploy - commerical MS Server OS on MS IIS/Biztalk/etc licensed servers.
  • BE: Lot of packaged solutions, some integration solutions, all commercial, are available. However, require licensing for deployments.
If Microsoft is going to try to adopt an open source community, they need to take a look at the Barriers to Entry and the Barriers to Deploy, particuarly from the commercial standpoint -- the companies that can spend the money aren't going to give their code back for free, while companies/developers that have low costs for the development and deployment environment are less in a pinch and like having their source code out there to help improve it's quality, particularly when the Barrier to Entry for someone else to look at published code is low.

No comments: