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. Iain _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
