[ajug-members] Too use Open Source or Not

N Ali n at nali.org
Wed Oct 10 16:30:57 EDT 2007


And use something like the planet (http://www.planetplanet.org/) to
aggregate blog feeds.

nick

On 10/10/07, Travis Bailey <mail at travisbailey.com> wrote:
>
>
> AJUG should install a blog...
> I added a post to my recently created blog for ya... needs material
> anyway:
>
> https://blog.travisbailey.org/?p=7
>
> behind a self-signed certificate right now, so not production grade.
>
>
> Travis Bailey
>  Travis Bailey Photography
> *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: Wednesday, October 10, 2007 11:11:38 AM
> Subject: Re: [ajug-members] Too use Open Source or Not
>
>  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
>
>
>
>
> _______________________________________________
> ajug-members mailing list
> ajug-members at ajug.org
> http://www.ajug.org/mailman/listinfo/ajug-members
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ajug.org/pipermail/ajug-members/attachments/20071010/f6887050/attachment.html 


More information about the ajug-members mailing list