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
