I agree, I think there is a movement afoot (if not named) that new frameworks will be truly decoupled -- being designed by war-worn veterans. The first frameworks were all massively coupled bells and whistles. The whole point of RoR is a pseduo-OO skin over a massively coupled Active Record system that can't really be extended without hula hoops. And Rails gurus love hula hoops.
One problem: users of open source love oodles of features, no matter how useless. Witness the sheer number of people who admit the primary way they choose a library is the last commit date and features list.
So if you write a solid library with just the right number of features, then it might get less consideration because you're not always duct-taping over poor design choices.
This is what happens when we glorify Internet Time. It becomes more about shipping and less about quality.
This is very true. It is a real issue in the open source world. http://github.com/codegangsta/martini tries to pride itself on minimalism. Thankfully the modularity of the project allows me to tell people to add features via other packages and repositories. Even though the product is solid it is difficult to communicate that the project is still active without having so many commits.
This is one of the reasons that I find the Golang package management philosophy refreshing in theory. "Master should never break" really prevents feature creep from coming in and promotes the use of solid packages that aren't always being actively worked on. Of course there are some major drawbacks wrt lack of versioning in Go, but I think the philosophy there overall is a very good thing for open source development.
Incredibly, people seem receptive to overly ambitious feature-creep-laden libraries even if they're completely half-baked. It's like they'd rather debug someone else's code than write it properly in the first place. IMO, there's few things more painful than when someone's library just doesn't work at all. The 'shiny' factor of communities usually indicates a lack of respect for good engineering. I much prefer communities that take coupling seriously; the only one I've found so far seems to be Clojure.
Please continue to push Golang away from fashion-oriented 'engineering.' I hope you take marketing seriously; it seems very possible for someone to create the next ultra-coupled-hack-of-a-Go-framework to rile everyone up and consequently forget all the lessons of minimalism.
I don't use the last commit date itself; I use how many issues, pull requests, and mailing list posts there are, how recent, whether the library author is replying, and how many others are using the library in their projects. For any reasonably sized library, there should at least be some of this happening. I don't want to take on the full development effort of the library by myself if I run into problems with it.
