Iain Duncan wrote:
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.
We do have http://bfg.repoze.org/trac/wiki/RoadMap but it's not very
PHB-consumable or very specific. Lately, framework direction has been
dictated almost entirely by my own whims. My whims lately have been informed
mostly by community input, as opposed to by Agendaless customer input, as was
the case several months ago, but still it's just my own whims.
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.)
I don't think BFG 1.X is in danger of becoming too stale, at least for the next
six months or a year or so. The point where what folks currently think of as
BFG is more likely to become stale is when we make changes to it that require
a major version number switch (e.g. 1.X - 2.X). In such changeovers, there
might be backwards incompatibilities that leave early adopters stranded on a
1.X series that receives less attention than a newer, cooler 2.X.
Hopefully we don't fall victim to this for stupid reasons, but nothing is set
in stone; often there turn out to be not-stupid reasons to ditch some portion
b/w compat in order to take advantage of some newer set of libraries or some
new platform, or whatever.
The best way to avoid problems if this happens is to make sure that the 1.X
series has a big enough userbase that folks step up to take over maintenance of
the 1.X series should it become legacy. So it's something of a chicken and
egg scenario.
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! ;-)
I'd actually like to get a book out there on the market based on the current
BFG documentation, if the licensing terms were right. I haven't shopped this
idea around at all to any publishers, but if anyone should know any who would
be interested in such a deal, I'd like to talk to them. I don't think there's
currently a big enough market, though, so I don't expect folks to be knocking
the door down. On the other hand, I don't have much doubt that there *will* be
a big enough market pretty soon, so it would be nice to get some sort of deal
lined up.
We are also loosely collaborating with Ben Bangert of Pylons, and we're hoping
to share more technology at the base. I think maybe there will be more to talk
about with respect to this around US PyCon time.
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.
I'd be happy to put the stuff I put in this email up there if you think it
would help. Or if you have wording suggestions?
But any official proclamation that includes something like this version will
be maintained until this date or feature X will be in version X we put up
there would be at least a half-lie or a guess. The folks who want long-term
certainty will need to purchase it, as they do with any open source projects.
- C
___
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
