Are you implying that Zope wasn’t a success? :P

> On Dec 11, 2014, at 14:44, Paul Everitt <[email protected]> wrote:
> 
> 
> One thing to note on that criteria…if one were to list the 3 biggest Python 
> web frameworks, they aren’t produced by a company. In fact, there was once 
> this big Python open source web framework that was managed by a company with 
> big money behind them...
> 
> —Paul
> 
>> On Dec 11, 2014, at 2:41 PM, pyramidX <[email protected]> wrote:
>> 
>> That makes sense, thanks.
>> 
>> With many big open-source projects there's a company backing it (e.g. 
>> Ansible there's a company providing support and services for the open-source 
>> product), and though there's no guarantee that it'll stick around, knowing 
>> there's a commercial incentive for a company to continue to maintain the 
>> project actively does bring a level of comfort.
>> 
>> Are there companies offering professional support or consulting for Pyramid?
>> 
>> On the project site there's 'Who's using Pylons Project software', didn't 
>> realize large public-facing sites like digg and cars.com are using Pyramid. 
>> Is there a more thorough list of these sites available? Or perhaps you might 
>> personally know of some other large public-facing websites that are 
>> currently using Pyramid extensively?
>> 
>> No worries about Pyramid's future, but it never hurts to get more knowledge.
>> 
>> On Thursday, December 11, 2014 2:28:25 PM UTC+1, Chris Rossi wrote:
>> 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.
> 
> 
> -- 
> 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to