[ajug-members] Too use Open Source or Not

J. Talafous jtalafous at gmail.com
Tue Oct 9 20:43:17 EDT 2007


Dead on.

On 10/9/07, Burr Sutter <burrsutter at gmail.com> wrote:
>
>
>
>
> 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
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>
>




More information about the ajug-members mailing list