Hey Chris et. al, I'm seriously considering switching my main platform
for our inhouse framework to mostly repoze.bfg with auxillary pylons
bits from the other way around, but have a few concerns that mostly
relate to making sure that clients buy into our platform of choice and
feel like they aren't all up the creek if we get hit by a truck (we're
small, one big truck could do it!) Have you guys considered adding to
the (wonderful) docs some sort of general bfg 'mission statement', long
range plan, future directions kind of deal? I think this would really
help bfg adoption, *if* that is a concern of yours and I'm not sure
whether it is.

What I am afraid of is the (mis?)-perception that a framework might just
hit the point where the core team says "well it does what we want, no
need for it to grow anymore". I totally respect an author's right to do
that, but as happened with Mochikit, it means the framework essentially
becomes a once off library and it becomes much harder to convince other
stakeholders that they are not investing money on a dying horse, and
thus harder for us to justify using it. ( Now dojo has ported most of
Mochikit's best bits, and it's essentially a legacy project.) 

Right now it's easy for me to sell my clients on Pylons because we have
decent books on Pylons, SQLAlchemy, etc, and that is reassuring to them
( it must be really easy for Django ). It's harder with repoze.bfg
because I can kind of point at zope, kind of point at the docs, kind of
point at the zope credentials of the team behind it, but nothing as
solid as a bound hunk of paper. So any marketing signs that this is
serious and won't be going away any time soon would help. I would also
be interested in seeing on there any mentions of future possible
collaborations with Pylons or Grok, as that also reassures people that
this won't just stop! ;-)

So I guess I'm asking for some sort of write up on the website
addressing those sorts of things *if* they are a concern of yours, and
if not, a clarification that they aren't and that it's a "use if it's
useful but don't complain about our choices" kind of deal, which is
absolutely an author's prerogative.

Thanks for all the awesome work again.

Repoze-dev mailing list

Reply via email to