Evan,
Regarding your comment about forking the code being a last resort, I'm not
too sure about that. In fact, I think forks are absolutely critical when an
OSS project is at a plateau. Forking gets a really bad name, but I think it
is critical to a project's evolution. Some of the most successful OSS
projects out there were a result of forks.
Especially when you look at a Linux distribution like Ubuntu. Ubuntu really
was forked just to get more frequent and fresh releases. Even today, it
still maintains the Debian base. It has a couple of add-on features.
I could easily see Stripes doing this. All it really takes is a few people
who are willing to prioritize some goals (usually high-impact defects or
enhancement requests)... and then the fork is done.
In my opinion, a fork is necessary with Stripes right now. No release in 9
months. A growing backlog of high-impact items. A community that is
expressing serious concern. Code that is committed or offered to be
committed without review or response. Nobody who can really hands the keys
over.
Sounds like the makings of a fork to me. Someone just needs to step forward
and do it. Personally, I would hope one of the original code contributors
would do it -- and then take a passive role. But usually for political or
personal reasons, that isn't done.
-- Rick
On Sat, Sep 18, 2010 at 7:02 PM, Evan Leonard <evan.leon...@gmail.com>wrote:
>
> Nikolaos,
>
> Thank you for the thoughtful summary of the state of things. Since I just
> popped up here recently with my opinions, I thought it might be useful to
> introduce myself briefly, so people know where I'm coming from.
>
> Starting in 2003, I began working at a startup in the SOAP/SOA world. We
> built a product using Struts 1.1 which was "the best thing at the time".
> And I worked to overcoming its warts. I added flash scope, view models, and
> a number of other things by extending the core struts processor. I started
> down the road of creating some fancy-pants UI controls that would maintain
> their state seemlessly across request cycles using a viewstate concept like
> ASP.NET. (I abandoned this idea later, but want to give you an idea of the
> experiments I did working with struts). By the time the app was done we had
> a 1400+ line struts.config file. I know the pains of struts well.
>
> Since then I've gone looking for something better. While still at that
> company we tried Grails, by bringing in the old app under a new grails app
> using the grails-struts plugin. Grails was, well, disappointing. You never
> can get away from the fact that groovy compiles to java before compiling to
> bytecode. The amount of reflection that happens to make a single method call
> is astounding. And then there's the magic stuff that appears in context
> somehow, and you have noway of knowing without digging through the
> documentation. Which brings me to rails.
>
> I've tried to prototype a number of things in Rails, and for all its buzz
> about being fast to develop, it never felt fast to me. The amount of time I
> spent going through documentation to understand what's in context was
> frustrating. I'm sure its super fast once you've spent a thousand hours
> learning it, but the ramp-up time is deceiving. There are a number of good
> things to learn from the design of the platform and the organization of
> community ecosystem however. (
>
> (I won't bother covering my opinions about Springsource. Others have stated
> the situation there well already)
>
> So, when recently I needed to select a new web framework and was pointed to
> Stripes by a former colleague and friend of mine I liked what I saw. The
> ability to customize Stripes is great (for the most part), the way it can be
> made to work with other frameworks is great (for the most part). But before
> committing to using it for the next year or more, I would really like to see
> an active community around it. Where there is a clear process for giving
> feedback, submitting patches, and generally contributing. This is the one
> area that is currently lacking. Yes, there are all the perception problems
> too that people have discussed. But if those are solved and there is still
> no clear way to contribute to the project, then the new interest won't turn
> into new activity.
>
> Stripes isn't perfect, I'm looking at integrating a different db layer
> other than hibernate, and I've found a few places I would like to be able to
> hook that are not currently hookable. I would like to be able to have my
> validations on my model classes and have them carried through to the view by
> Stripe's validation layer. But I don't know who to talk with to make these
> things happen.
>
> I've seen other projects come to forking the code when the current owners
> of the project aren't able to continue or turn things over to others. That's
> usually the last resort. I certainly don't have the time to become a core
> maintainer on a project. But I do have time (and experience) to help a
> community organize itself around a good purpose. And it sounds like
> continuing the spirit of Stripes is a good purpose.
>
> So with that, I hope to hear from the folks in the "core" currently. I
> hope we can engage in some discussion about what the next steps are with
> respect to code ownership and the contribution process.
>
> Thanks so much for all the work that been put into this project so far.
>
> All the best,
> Evan Leonard
>
>
>
>
> On Sep 18, 2010, at 10:09 AM, Nikolaos Giannopoulos wrote:
>
> > Ben,
> >
> > You have made it clear that you needed to get away from the code back in
> > June after having made a flurry of commits. Everyone understands and
> > appreciates what you have done for Stripes as you have single handedly
> > maintained Stripes for quite some time (I assume since its beginnings
> > with Tim) and have been an incredible driving force IMO.
> >
> > But the time of a single developer cobbling together code OR merely
> > accepting patches that are ready and tested from the community - but not
> > having the time to integrate them - must be over. At some point in time
> > we need to stand aside to see a project grow otherwise we will - and not
> > to be dramatic - smother it and indeed it will die... .
> >
> > There are developers like Evan, Nicolai, myself (down the road) and
> > others in the wings (whose names I don't have readily with me but have
> > voiced themselves already) that are "ready" to get involved **today**
> > and / or contribute their extensions that they have built for their real
> > world projects... and yet the lack of response to requests on how to get
> > involved is quite unsettling to say the least.
> >
> > Another area... 1.5.3 was released on December 16, 2009 yet a full 9
> > months later it still does not appear in Maven Central. One suggested
> > solution was to setup a Sonatype repo for Stripes so that it
> > automatically syncs to Maven Central. In STS-738 back in May of this
> > year you said "In case you missed my note on the mailing list the other
> > day, I'm working on getting this going through Sonatype. I'll resolve
> > this issue when it's done." The fact that it isn't setup is not my
> > biggest concern and is not a problem as in the end you volunteer your
> > efforts / time.
> >
> > However since then others including Samuel Santos and Nathan Maves have
> > offered to help setup a Sonatype repo for Stripes - which they both have
> > stated they have experience doing - yet once again no reply to their
> > offers to help. Once again this is unsettling... .
> >
> > This thread is by no means meant to be critical of your contributions...
> > as they most likely overshadow everyone else's in this community for
> > their extent and dedication. This is meant more as a wake up call to
> > all those that hold the keys to Stripes. I assume that includes
> > yourself, Freddy and Aaron but don't know for sure... .
> >
> > In my mind 3 things need to happen for Stripes to prosper:
> >
> > 1) Getting Stripes automatically sync'd up through Sonatype will
> > deflect the "perception" that the project is stale i.e. 9 months since
> > its last release is no big deal... not having its latest release "out
> > there" where it can be *effortlessly consumed* *IS* IMO.
> >
> > 2) Some process needs to be setup to allow others to get into the
> > ground floor as contributors. This OSS at its best. There are numerous
> > talented people on this list alone that not letting go of the keys WILL
> > kill Stripes. Period. As I personally have not led any OSS projects I
> > am not sure what the best procedure / process to follow is nor do I know
> > where to start but I'm sure others can chime in on how to properly
> > initiate this. If this was truly difficult then OSS would not exist.
> > This is *CRITICAL*.
> >
> > 3) All the other good initiatives that have been started need to
> > continue like setting up a new web site, a better place for forums
> > (mailing lists are wonderful but people search the web more often than
> > mailing lists for quick answers), deciding on how to partition
> > extensions, stacks, etc... (of course there is debate here), etc...
> >
> > But if 1) and 2) don't happen then yes not to sound dramatic Stripes
> > will surely die... not b/c it isn't a great product... but b/c people
> > like myself and others in the community will feel that they are beating
> > a dead horse in trying to get involved... and will simply give up and
> > look elsewhere. If you alienate those that the "early adopters" /
> > "sneezers" then 3) won't matter at all.
> >
> > Ben, Freddy and / or Aaron... its time to step up to the plate... to if
> > anything hand over the keys and take on a reviewer / advisor role in the
> > future of this wonderful framework.
> >
> > Regards,
> >
> > --Nikolaos
> >
> >
> > Evan Leonard wrote:
> >> Nicolai,
> >>
> >> Absolutely. This is a must. I am starting to use Stripes for a project
> and want to participate in the community. However, its not clear how to do
> so!
> >>
> >> Is it clear in the community how decisions are made about these things?
> Are there certain "core" developers with some level of authority? Forgive me
> as I'm just coming up to speed.
> >>
> >> Evan
> >
> >
> >
> ------------------------------------------------------------------------------
> > Start uncovering the many advantages of virtual appliances
> > and start using them to simplify application deployment and
> > accelerate your shift to cloud computing.
> > http://p.sf.net/sfu/novell-sfdev2dev
> > _______________________________________________
> > Stripes-users mailing list
> > Stripes-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
>
>
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
