[ajug-members] Too use Open Source or Not

[Travis Bailey]

I agree substantively with all your points.
I think you might miss one Burr... ;-)

F) Prognosticate and Pray:  When making decisions about which technologies to use on a new project, I think it is important to consider it's maintainability.  No one small firm is likely to be able to take an OSS project into the mainstream, but that small firm is looking to leverage the community with support of frameworks and technology.  When a team chooses to use newer projects like Struts2, Spring2, jBPM, Drools, etc... they are really just trying, in part, to bet on the horses that they think will be mainstream a year or two from now.  I think part of the value of developing software for a company is developing that software with technologies that are appropriate and hopefully are popular enough the customer can find developers to support and maintain the software for years to come.  Just because a technology is best doesn't mean it will become mainstream...

A lot of our decisions about the technology we use surrounds these points:
Does the technology solve a business problem?Will the technology offer a value proposition during it's lifecycle (bleed to maintenance)?Is the technology within a core skillset of the largest pool of developers? (minimize the skillsets needed for support)

We started this project last February with a target initial release of end of Q1 2008 with a subsequent release schedule likely lasting another year for "recognized" features.
It is really hard to guess what technologies I will be able to hire smart folk for in 2009 without paying through the nose.
 
Travis Bailey
 www.travisbailey.com
 404.664.7782 (c)

        "The greater the artist the greater the doubt. Perfect confidence is granted to the less talented as a consolation prize." - Robert Hughes



----- Original Message ----
From: Burr Sutter <burrsutter at gmail.com>
To: ajug-members at ajug.org
Sent: Tuesday, October 9, 2007 12:25:55 PM
Subject: [ajug-members] Too use Open Source or Not





 
 

 

 


<!--

 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;color:windowtext;}
 _filtered {margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{}
-->






Travis’s recent response to my inquiry about jBPM has
sparked an idea that I want to discuss with the group (thank you, it created an
interesting thought and I’m NOT picking on Travis, please don’t
take it that).   
 

  
 

He made a point that jBPM had “headaches” and
seemed to have flaws in a given area (oracle & forking) both of which are I
think are perfectly reasonable assertions as someone who is interested in or
trying to use a technology.    So here is my thought…
 

  
 

Open source projects tend to have a number of quirks as they
are primarily driven by small numbers of contributors, working around the
global, in many cases during nights & weekends.   The successful
 OSS (open source software) projects often have a charismatic
leader, someone to evangelize the core ideas behind the value for the
 OSS project.   With that
said OSS-based projects often lack formal documentation & QA resources and
since most OSS 
projects are founded by coders, not tech writers/quality engineers you can see
the problem.  That is where the community comes into play and adds significant
value.  Struts benefits from having numerous individuals writing books on that
framework,  consulting & training companies offering services and from
having 1000s of users put it through the wringer in every possible way
imaginable.   Therefore the result is a well documented and well QA’d piece
of technology. Perhaps of the worlds best documented & QA’d
technologies.  The community is also serves as the BA role and in some cases
the project manger role (demanding the core contributors finish on time by
nagging them to death, offering to buy them beer & steak dinners).
 

  
 

Now here is the “catch-22” (or chicken & egg
issue), in order to get all of those extra documentation, QA and BA resources,
you have to be pretty popular and pretty “mainstream” where 30+% of
most Java users know of or are attempting usage of that technology.  Struts,
Spring, Hibernate, Ant, JUnit are just some that fall in that category.  The
trick is getting popular (therefore getting all the goodness of the community)
while at the same time have good enough quality, docs, email list support,
etc.    Obviously there is the complexity factor as well.  Ant and JUnit are
pretty simple tools therefore it is easier to provide enough quality, docs
& email list support to get a community.
 

  
 

Here are the options I can think of:
 

A) Wait:  So you might wish to wait to adopt a technology
after it has gained popularity.  Struts, Spring, Hibernate, Apache WS, Ant,
JUnit, JBoss App Server are all “safe bets” and have been proven by
the usage of thousands of individuals and companies.  However, this puts you
very late to the game on OSS 
innovation. People adopting Struts now would be considered to be “laggards”
while people adopting MyFaces, Facelets and/or Seam would be considered “early
adopters”.  
 

  
 

B) Bleed: Or you might wish to bleed a little and adopt the
less mature technology and participate in the community (great community
members can simply be those who develop a test case to illustrate the issue and
attach it to a Jira task).   Bleeding isn’t fun but you might want to
have the most innovative tech.  You might want Struts2 or Spring2 or Hibernate
Shards or an OSS-based ESB to solve your business problem and you are unwilling
to build the framework from scratch or unwilling to pay the huge fees to a
major commercial vendor to provide closed source software.
 

  
 

C) Pay: To pay some open source “consulting”
& “support” company some dollars to help you overcome the lack
of docs, best practices, etc and perhaps even track down and fix bugs on your
behalf.    There are several organizations attempting to make a profit in this
space. Some have already failed as businesses.
 

  
 

D) Build: Build your own solution that solves your end-user’s
specific use cases.  That is quite common for MVC, IoC/DI, ORM-lite and ESB. I’ve
met several who built their own Tomact/App Server like thing before. Those who
built their own clustering/grid-like frameworks. Plus a lot of custom ESB-like
solutions.
 

  
 

E) Sell: If there is only a small community for a technology
but you really, really wish to use it then you work your butt off to evangelize
it. You become a salesman.  A recent example of this was Ruby on Rails and Dave
Thomas.  He was the “maven, connector & salesman” who helped it
reach its tipping point (must read: Blink & Tipping Point).  Bruce Tate
also falls in that category. Now they make great money selling consulting,
books, training, etc.  I’ve personally been accused of the same, as far
back as pushing the notion of the internet, modems, NCSA httpd and CGI for a
new application platform OR even the concept of server-side Java as an
application server. Some of you were around 10 to 13 years ago when I was “selling”
those ideas in Atlanta .
 

  
 

I think this is important concept for current & future
software architects, those people who have to make hard decisions about which
tools/frameworks they’ll embed in the solutions they’ll create for
their end-users.  Sometimes we gamble big (try any JAR file we find on
sourceforge.net) and sometimes we don’t gamble at all (we use exactly
what IBM tells us to use). 
 

  
 

What do you think about this topic?  
 

  
 

Burr
 







-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20071010/fe7f923a/attachment.html