Ok, less snarky version--one doesn't know the future, but the community
around Pyramid is cohesive enough that it should endure for some time to
come.  Enough businesses are using it in their core infrastructure that
it's unlikely the community would just shrivel up overnight.  The reason
there are so few features slated for future release is because Pyramid,
itself, is starting to feel finished.  It does what it does really well and
we don't feel that we're wanting for features.  The bulk of new development
is around layers on top or add-ons for Pyramid--projects that contribute to
the Pyramid ecosystem, but not necessarily to Pyramid core.  Because,
really, core already has most of the features anyone wants at that layer.

Chris

On Thu, Dec 11, 2014 at 6:34 AM, Steve Piercy <[email protected]>
wrote:

> Pyramid is "as is".  No warranty.
> https://github.com/Pylons/pyramid/blob/master/LICENSE.txt
>
> If you want people to maintain something for you indefinitely, then you
> need to make an agreement or contract for services.  Sorry to be snarky,
> but come on!  Pyramid is a free and open source project, and expectations
> need to align with that reality.
>
> --steve
>
>
> On 12/11/14 at 3:12 AM, [email protected] (pyramidX) pronounced:
>
>  I love Pyramid and my only thought is will it be maintained indefinitely?
>> Say if the few main committers move on is there some sponsor who will step
>> in? (I have similar thoughts about SQL Alchemy which my Pyramid app uses
>> heavily.) My other thought is whether there is a roadmap for the future of
>> Pyramid. It's good to know the project has a plan of where it wants to take
>> things. I see https://github.com/Pylons/pyramid/blob/master/TODO.txt#L116
>> but there's only one new feature listed for each release like 1.6, 1.7, etc.
>>
>> On Wednesday, December 10, 2014 7:19:26 AM UTC+1, lostdorje wrote:
>>
>>>
>>> +1 to all the responses regarding there being Python and Ruby developers
>>> vs there being Django and Rails developers (and even Wordpress
>>> developers...*cough*...vs PHP developers). I got my degree in Computer
>>> Science, so I just consider myself a developer, period. The point of these
>>> narrowly scoped dev types is well taken. I wouldn't want to hire anyone
>>> whose skill set is so tightly tied to a framework. I'd guess in most cases
>>> such developers wouldn't 'scale' well in a growing startup.
>>>
>>> And +1 to Torsten's comment about Python, rather than just Pyramid
>>> itself, having a user base with strong programming roots beyond just web
>>> development within a framework.
>>>
>>> And +1 to Jonathan. Totally agree with you on: Lower-level frameworks
>>> like Flask, Pyramid, etc tend to attract developers more interested-in or
>>> experienced-with the language, the user pool is smaller and self-selecting.
>>> This has both advantages and disadvantages, but in terms of getting the
>>> best talent on board, it seems the best talent would definitely be more
>>> interested in/experienced with the 'lower level' frameworks.
>>>
>>> Thanks for all the insightful responses, it helps me confirm I still
>>> believe Pyramid is the right choice for the startup we are building out.
>>> Regardless of technology stack, we will only being hiring *real* developers
>>> and not devs who can hide behind a framework as a crutch, obfuscating the
>>> depth of their real technical knowledge.
>>>
>>>
>>> On Wed, Dec 10, 2014 at 12:44 AM, Jonathan Vanasco <[email protected]
>>> <javascript:>> wrote:
>>>
>>>   I'll preface this by saying that I'm biased towards Pyramid, and when
>>>> I  have to program - I prefer it.  I begrudgingly program though - I'm
>>>> usually  on the business/product/management side.  But in the past 3
>>>> years:  I've  been working extensively with Pyramid on a personal project,
>>>> was CTO of a  large media company that had a re-deploy onto Rails
>>>> in-progress (a mistake  that was scrapped), and was the Product/Tech
>>>> advisor to medium sided media  company that was on Django.
>>>>
>>>>  If you're doing a "Startup" that is in any way unique or looking to
>>>> scale, I would only consider doing it in Pyramid.  If it's going to be
>>>> essentially a lot of basic functionality, something off-the-shelf (blog,
>>>> e-commerce) and nothing really proprietary or large scale, then
>>>> Django/Rails would be perfect.  Aside from the language difference, Rails
>>>> and Django are basically the same  (there are some differences in
>>>> approach,  but both are very high level frameworks).  If you are a building
>>>> a one-off  project, an advertising campaign, are a dev-shop working for a
>>>> client's  time-limited event, etc -- then Django/Rails are what you want,
>>>> and Pyramid  would be overkill.
>>>>
>>>>  Pyramid / Pylons is a very low-level framework.  You'll spend more
>>>> time  and energy getting some basic things done at the outset, but you
>>>> won't ever  be constrained by the Framework or Data Model, and your
>>>> velocity will  improve or stay consistent as you need to pivot or scale.
>>>> You can make  large changes with little work, and easily introduce "quick
>>>> fixes" if  needed.
>>>>
>>>>  Django is very high level.  It's so high-level, that most people I
>>>> know  consider it more like editing configuration files than writing
>>>> Python.   You'll be off to a quick start in basic functionality, but
>>>> quickly feel  constrained by a fairly rigid API and the need to do things
>>>> the Django  way.  Your velocity will plummet as the project moves onwards.
>>>> It can be  exceedingly hard to implement a "quick fix", because the
>>>> framework is so  tightly integrated.  Adding new functionality and
>>>> addressing bottlenecks  can be aggravating.
>>>>
>>>>  Rails is basically the same as Django, except it's in Ruby.
>>>>  In terms of hiring... from firsthand experience it is incredibly hard
>>>> to  find *good* Django/Ruby developers.  This has less to do with the
>>>> concept of a "Developers Market"  that others noted (which is true) than
>>>> it  has to do with the overall talent pool.  While there are a lot of
>>>> really  brilliant Python/Ruby developers in the Django/Ruby community, I've
>>>> found  that the majority the community are Django/Ruby developers -- NOT
>>>> Python/Ruby developers.  These people tend to be pretty unfamiliar with
>>>> the  core language and just know the framework -- usually through a HowTo
>>>> book  or some sort of bootstrap class.  Bad developers flock to the
>>>> buzzwords: to  Java, then to PHP, and then to Django/Rails.   The result is
>>>> that the  signal-to-noise ratio in the Django/Rails applicant pool is
>>>> ridiculously  low -- and you can spend months trying to source candidates
>>>> worth bringing  in to an interview -- only to end up paying a premium for
>>>> bad developers  who simply know the stack.  I've had Rails/Django devs with
>>>> 2 years  professional experience demand higher compensation than developers
>>>> with 10  years of work experience who were experts in a field.  It's a
>>>> ridiculous  premium.
>>>>
>>>>  Lower-level frameworks like Flask, Pyramid, etc tend to attract
>>>> developers more interested-in or experienced-with the language, the user
>>>> pool is smaller and self-selecting.  This is simply a correlated effect to
>>>> the popularity of the frameworks.  So you might identify 100 candidates
>>>> for  a Rails/Django position, but only want to interview 2 after seeing
>>>> their  resumes... meanwhile you might identity 5 candidates for a
>>>> Pyramid/Flask  position and probably want to bring all of them in.  There
>>>> are definitely a  lot more "good" Rails/Django developers than
>>>> Pyramid/Flask developers --  but you'll have to sort through hundreds of
>>>> applications or profiles to  find them.
>>>>
>>>>  If you do go the Django/Rails route, I would suggest doing all your
>>>> recruiting by targeting people through contributions to open source
>>>> projects.  All the best applicants I've met were either active
>>>> contributors  to larger projects, or had a few small (and well written)
>>>> libraries of  their own -- and I could quickly judge if they actually knew
>>>> Python/Ruby or  not.
>>>>
>>>>
>>>>   --  You received this message because you are subscribed to the
>>>> Google Groups  "pylons-discuss" group.
>>>>  To unsubscribe from this group and stop receiving emails from it, send
>>>> an  email to [email protected] <javascript:>.
>>>>  To post to this group, send email to [email protected]
>>>> <javascript:>.
>>>> Visit this group at http://groups.google.com/group/pylons-discuss.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>
>>>
>>
> ------------------------
> Steve Piercy, Soquel, CA
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/pylons-discuss.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Reply via email to