[ajug-members] Too use Open Source or Not

Burr Sutter burrsutter at gmail.com
Wed Oct 10 11:11:38 EDT 2007


That is a good one.

 

We should find the time to craft this into a blog entry or something..

 

 

  _____  

From: Travis Bailey [mailto:mail at travisbailey.com] 
Sent: Wednesday, October 10, 2007 8:41 AM
To: ajug-members at ajug.org
Subject: Re: [ajug-members] Too use Open Source or Not

 

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

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/5e908f52/attachment.html 


More information about the ajug-members mailing list