Yeah the dedication is the necessary ingredient for sure!
Once we've got that, tools can help though :-)
Personally, I'm a fan of Mercurial, for much of the same reason that Google
Code is:
http://googlecode.blogspot.com/2009/04/mercurial-support-for-project-hosting.html
Evan
On Sep 21, 2010, at 9:57 AM, VANKEISBELCK Remi wrote:
> Yeah, been busy !
>
> Well, I guess that (even at my young age !), I'm kinda old fashioned... :P
>
> Actually I wasn't speaking about the tool. What I meant is that whetever the
> hosting platform, you can always contribute in various ways. No need to have
> all privileges for that, it's only a matter of goodwill.
>
> We've had countless contribs in the past, using just SVN, patches, plus the
> good old mailing list. It's our dedication that paid off. Not the tools we
> used.
>
> For anyone interested in contributing : build that damn website, send patches
> for bug fixes, propose your ideas on the ML, advertise to your
> friends/colleagues, post in blogs... this is what will keep Stripes alive
> (when Ben will retire on a beach in Tahiti... :P).
>
> Cheers
>
> Remi
>
>
> 2010/9/21 Jeppe Cramon <je...@cramon.dk>
> Hi Remi
>
> Long time :)
>
> IMO forking is a good thing, IF it's done in Git style where it easy to keep
> up with those who have forked the master and push/pull between those
> interested :)
> It makes it so much easier to experiment and do patches and leave them for
> everyone to see, including the Stripes comitter, if it's hosted in you own
> GitHub repository.
> Having to fetch Strips sourcecode from SVN, create a patch file and send it
> in and hope that someone will accept it, is just too 2000 ;)
>
> /Jeppe
>
> On Tue, 21 Sep 2010 16:25:19 +0200, VANKEISBELCK Remi <r...@rvkb.com> wrote:
>
> Hi folks
>
> I've been following this thread not really knwoing how to responde, Ben, you
> took the words out of my mouth :)
>
> I'm also perfeclty happy with Stripes as is. Sure more developers would be
> agood thing. But forking like crazy etc... not sure this will help. Nothing
> prevents anyone to experiment with the codebase, and send their contribs. I
> have no doubts they will be accepted if they are worth it, and inline with
> the Stripes spirit.
>
> Cheers
>
> Remi
>
> 2010/9/21 Ben Gunter <gunter...@gmail.com>
> Well, it looks like life picked a bad time to get busy for me. I just now got
> around to catching up on this thread. I'm sure my silence caused some
> concern. Sorry about that.
>
> I completely agree with the sentiment that we need eager new developers to
> contribute to the project. Those who know me know that I'm not about politics
> or control or ego. I would love to bring some eager new developers in to help
> rejuvenate the project.
>
> There was a time a few years ago when I had that same enthusiasm for
> developing Stripes. I answered lots of questions on the mailing list with
> tons of code samples. I started the Stripes Extras project to add some
> security to the binding stage so developers wouldn't have to worry about evil
> stuff getting poked into their ActionBeans. I had bigger plans for Stripes
> Extras, but Tim took notice of my activity and invited me to contribute
> directly to the Stripes core. I accepted, and the features of Stripes Extras
> were merged in for Stripes 1.5. Freddy and Aaron and a few others joined in
> on the 1.5 effort, and we finally released what I think is a pretty nice
> product: binding security, clean URLs, DynamicMappingFilter, minimal
> configuration, improved type conversion and formatting. Not too shabby.
>
> What we were then was a great group of developers with a clear vision for
> what we wanted Stripes to be and a singular focus on making it happen. What
> we are now is a great group of developers who have a framework with which
> we're quite satisfied. I remember clearly that when Tim brought me in he said
> -- I think it was on IRC -- that he was happy with Stripes as it was. That is
> where I stand now. Like Tim was then, I am happy to hand over the reins to
> someone who can drive the project forward, while offering any help I can
> along the way.
>
> Over the last few years, I have heard time and time again the chorus of "we
> should do this" or "we should do that." What I have learned, though, is that
> more often than not it really means "you should do this" or "you should do
> that." I have poured hours and hours into finding and fixing bugs that do not
> affect me personally. Generally, it's very difficult to get cooperation from
> people in testing patches to ensure the bug they've reported is fixed.
> Complaints about how something works or does not work are rarely accompanied
> by a solution to the perceived problem.
>
> My point is that talk is cheap. Who out there is really willing to dig in and
> learn the Stripes code and dedicate a good chunk of time on a regular basis
> to make it better? Who is willing to design a new web site? Who is willing to
> review and correct and improve the documentation? Who is willing create and
> maintain a Stripes-centric blog with regular articles?
>
> If you are willing and able *right now* to start making a real contribution
> to the project, then respond to this email and commit to it. Let us know your
> name, your history with Stripes, how you want to contribute, and any other
> information that you think is relevant. If you can't contribute now but hope
> to be able to in the future, then please wait until that time comes to speak
> up. What I want is to know who we have in this group who can help breathe new
> life into Stripes starting today. Let's hear it.
>
> -Ben
>
>
> On Sun, Sep 19, 2010 at 2:51 PM, Jeppe Cramon <je...@cramon.dk> wrote:
> Hi guys
>
> I've been following this resurrection thread for a while and even though I
> contributed some core parts to Stripes in the early days I haven't really had
> the need for something like Stripes in a long time (for instance it lacks
> proper REST and Comet style support).
>
> IMO Stripes has faded because it has been too difficult to participate, add
> patches and features.
> I like that the core of Stripes is kept tight, with focus on extensibility
> and what's the core things for an Action based MVC framework.
> The low learning curve and the easy extensibility was what attracted me to
> Stripes in the first place, but the lack of progress & new releases is
> hurting Stripes.
>
> Since this thread has appeared and have started a good discussion, I think
> it's important to reach a consensus on where to take Stripes.
> IMO if this thread dies out with any clear forward action, then Stripes is
> going to whither.
>
> I agree with Rick, forking would be a good way to move forward.
>
> My suggestion is to put Stripes on GitHub and allow people for Fork it like
> crazy - see what the community can come up with and harvest the best ideas by
> pulling from the best contributers.
> But IMO it's important that someone like Ben, Aaron or Freddy be the one(s)
> maintaining the "official" Git Master and decide what gets pulled into the
> official Stripes release.
> Perhaps someone will come by and create a fork that blows everyone away -
> let's see what could happen ;)
>
> /Jeppe
>
> On Sun, 19 Sep 2010 20:27:21 +0200, Rick Grashel <rgras...@gmail.com> wrote:
>
> 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
>
>
>
>
> --
> /Jeppe
>
> ------------------------------------------------------------------------------
> 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
>
>
>
>
>
> --
> /Jeppe
>
> ------------------------------------------------------------------------------
> 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
