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.
