From: Joyce P. <tru...@ya...> - 2003-12-16 20:48:01
|
Hi Kragen, Thanks for the passionate response -- I was a bit worried at all the commonsensical "Just make nicer builds" responses, with no one really addressing my main point: are we all cool with the choices we are making about the users we're targeting? > What is this about being tied to Apache? The Python event router isn't > tied to Apache, and never has been. I agree that the Python server is not tied to Apache in a technical sense -- but I think it should be in a marketing sense, at least for a browser-based package. I thought we were all agreed on this, but evidently not -- so I guess the floor is open to discussion again. > In the product we're deploying pubsub.py in, we have Apache, but as it > happens, Apache and pubsub.py never talk to each other. (Yet.) So this depends on your point of view, right? You're thinking "Do I need to add Apache to the Python server for functionality reasons?" -- in which case the answer is "Obviously not". I submit that the average user (or at least the average in-the-browser user) is going to be thinking "How can I add this to my existing setup, which is Apache-based?" -- and therefore that is the real question we need to answer. This is a point I was never able to get across at KN, and evidently am failing to get across in Mod-pubsub too: people have existing shit, and we need to tell a story about fitting neatly into the interstices of their existing shit. Where is the value in continuing to stubbornly insist "we are our own thing, we don't need no stinkin' web server" to a bunch of people who don't want or need to hear that? Look at PHP. Are they technically superior to Python? Evidently not. So how did they grow that huge community? They targeted the huge mass of pre-existing Apache and IIS users as their market. They did everything they could to make it easy to coordinate with Apache, and then with IIS. They didn't have any qualms about categorically stating that PHP is a web-development language, even though it can do other things. The PHP guys have focus and clarity in the problem they solve and the audience they're pitching to; while Python has taken the other tack of marketing themselves as a general-purpose programming language. I respect the crap out of the Pythons, but I want Mod-pubsub to be PHP. :-) So the more I think about it, the more I think we are scaring newbie users off because of lack of focus. There are just too many options, and we try to cover them all in one go -- we tend to babble something like, "We have two servers, one that's an Apache module and one that might or might not be run with Apache, and we have a gazillion clients in every programming language on every platform, and the whole thing can do everything and nothing!" Not a very effective pitch, as amply demonstrated by our low conversion rate of interested people to active developers. So my proposals are simple: 1) Divide the distro up into a webdev package, a Windows package, and an other programming languages package. Nail the concerns of each audience. 2) For the webdev package, target pre-existing Apache users as our audience. 3) Agree on a strategy, so maybe we could make a statement about Mod-pubsub without a mass of qualifications attached. This doesn't make us look flexible and precise -- it makes us look like we don't know what the heck we're doing. > I really wish mod_pubsub were under the GPL, because right now, it's > pretty tough for me to get open source enhancements out of AirWave These are largely internal corporate problems into which I can personally have no influence. KN released their stuff under a BSD-style license, as you know. I have no insight into whether your crew would even have used Mod-pubsub if it had been GPLed. If there's anything we could do besides changing the license to help you convince your bosses, let us know -- maybe we could send Rifkin over there to give his "Open Source is good for business!" talk. > I think we should build as many applications as possible with mod_pubsub, > and encourage other people to do so, too. Couldn't agree more. Unfortunately, someone has to write docs and implement new build processes. JP |