What is Pylons' marketing message? Who are the target users? What essential things should the PylonsHQ site say? Add your thoughts here.

Existing content

"Pylons is a lightweight web framework emphasizing flexibility and rapid development."

"Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design."

"Ruby on Rails is a web framework, which is optimized for programmers happiness and sustainable productivity"

These are all general terms that apply to any framework following the original Rails vision (MVC + routing). Need to distinguish Pylons more from these frameworks.

Questions

1. Who is our Target group?
a.) Decision maker- Who is going to take dicision on which web framework to be used for each project
b.) Influencer- can be a developer/Client, etc..They can influence the decision maker

2. a.) What is a webframework from Decision maker's point of view
b.) what is a web framework from Influencer's point of view.?

3. a.) How is pylons different from others - decision maker's point of view
b.) How is pylons different from others - influencer's point of view

4. a.) Which problem in Decision maker's life can be solved with pylons but not with any other framework.
b.) Which problem in influencer's life can be solved with pylons but not with any other framework.

5. The most important point- Set an 'measurable' objective/target for the marketing effort

Clients are nervous that frameworks come and go so quickly, and that support for them can dry up. For instance, the TurboGears developers are not interested in maintaining version 1, and companies with existing TG1 apps are finding it hard to attract programmers willing to maintain them. Given that the Pylons developers are pursuing both Pylons 1.0 and a new Pypes framework, how can Pylons avoid this reputation?

Target users

Nobody wins if we market Pylons as if it appeals to the same people as Django or RoR. Maybe they get taken in for a bit, then they leave dissatisfied, and spread the word. Whereas when we attract the customers (users) who really are looking for what makes Pylons different, the opposite happens, they are excited, they spread the word, maybe they contribute back, less FUD and misinformation abound. We need to make sure that the 'right users' are coming to Pylons, and accept that it is going to always be a much smaller user base than rails or django. --Iain Duncan

There are multiple target users. The primary userbase is more technical app-developers who appreciate Pylons' unique flexibility. But we also want to capture at least some of the "I just want to build a website easily" market. Django does has some users and fanboys that Pylons may consider not worth the effort of supporting. If so, we need to distinguish what those characteristics are. --Mike Orr

Talking points

Pylons, Django, Rails, and TurboGears all share a basic approach, which includes MVC and some form of routing. Pylons and TG are different because they're built on top of third-party packages. Pylons' unique features are (1) a minimal base featureset (2) that easily allows the app-developer to swap in alternate implementations. The problem with emphasizing this on the home page is that many users don't need this customizability and don't want the complication of thinking about it – they just want to follow the HOWTO. --Mike Orr

Pylons' flexibility makes it easier to adapt for the future, because you never know what your future needs will be. Loose coupling means you can switch in a better implementation of a piece if one comes along, the oringinal becomes unmaintained, or the default does not meet your needs.

Long-term support

The Pylons core is essentially finished; 1.0 will just have some minor changes on the periphery. After that it will go into maintenance mode, with few new features being added, except what's necessary to keep up with changes in Python or the web application art. This will make Pylons a good platform for production because it won't be changing rapidly.

New-feature development is tentatively moving to the Pypes framework, which has more modularity than Pylons can provide, and which can run a Pylons-compatible API. (Pypes is in pre-alpha, so some of these features do not yet exist.)

"Pylons has always been about legacy support and helping users migrate, even in pre-1.0, and will continue to be oriented to making it easier to maintain and migrate older apps." --Ben Bangert, Pylons co-creator and lead developer

"I think the fact that Pylons cared about supporting existing apps enough to have 1/3rd of its pre-1.0 code-base be legacy support and deprecation warnings, should speak volumes about caring about business customers. Legacy apps happen everywhere when the code-base gets huge, and moving forward becomes more problematic." --Ben Bangert

"Large company rich webapps don't benefit so much from some of the features I'm looking for when I develop smaller websites with various bits like my new blog, or the PylonsHQ site. So for my own other various things, I need better pluggability, one of the things Pypes helps resolve in addition to bringing repoze and Pylons together." --Ben Bangert
[In other words, large applications often just need the solid base that Pylons provides, while smaller apps are more likely to benefit from off-the-shelf components and a multi-framework approach, which will be easier to do in Pypes.]

"Quixote is a good model. Its heyday was 2002-2005. The developers have declared it "finished" and are directing new features to a new similar framework, Qp. But bugs in Quixote are still fixed, and if somebody contributes a feature patch it's considered. It keeps up with essential changes in Python such as Unicode and 2.6. (Currently, 2.6 broke Quixote's PTL import hooks and perhaps SCGI, so the
developers are trying to find a migration path for existing applications. Users are [deleted list of workarounds].) So one could say that Quixote has been in supported-but-finished mode for 2 years or perhaps 4. And I assume it will remain that way at least as long as Quixote applications exist and the MEMS Exchange (which pays the developers) exist. Or until changes in Python just make Quixote unviable to support except in older versions." --Mike Orr

Dependencies

Pylons has more dependencies than most similar frameworks. This can be a concern to clients considering Pylons, because dependencies can become unmaintained, broken, or uninstallable. Pylons 0.9.7 has the following direct and indirect dependencies: Beaker, decorator, FormEncode, Mako, Nose, Paste, PasteDeploy, PasteScript, Routes, setuptools, simplejson, WebError, WebHelpers, WebOb, WebTest. However, most of these are maintained by Pylons developers so can be considered part of the framework. Only decorator, Mako, Nose, setuptools, and simplejson are maintained by non-Pylons developers. Of these, only setuptools and simplejson have fragilities. Setuptools does a complex job that can break on some computers, and any problems it has are Python-wide issues. Simplejson's problems are in its "C" speedups, which can sometimes be difficult to compile/install on Windows. However, simplejson is not used by the Python core but only for optional decorators, and it works fine without the "C" speedups if you configure it right.

Look alive

As development slows after 1.0, it's vital to maintain some activity on the mailing list and website to reassure people that Pylons is still being maintained.

Pylons' influence

Perhaps Pylons' greatest asset is influence rather than popularity. It's gaining respect and market share among those who know a lot about Python frameworks. (There's a selling point for newbies.) It may become the "central" framework in the way Debian has become central among Linux distributors. It may not be the most popular, but it's central because it's vendor neutral (doesn't favor one company over another the way RedHat or Fedora do), and forms a reference implementation. Pylons' use of Paste, Beaker, Routes, etc, validate those libraries and has encouraged other frameworks to adopt them. Pylons' smallness makes it nimble. We can use ToscaWidgets without being tied down to it. We can take our time evaluating AuthKit vs repoze.who/what. We can become the first adopter of whatever future library may appear, and prove its (un)usefulness to the wider Python-web world. Other frameworks reject Pylons' design decisions, but they keep looking at Pylons for ideas, to see what works. So Pylons has an influence much wider than its userbase.