Slashdot Mirror

isn't this related to the Trojan Horse Issue that the ZOPE guys posted yesterday?

I'd like to see a persistent scripting language which is a first-class peer of the server process. Yes, I know you can do this with Apache if you load enough modules, but I view that as cruft. Has anyone started over again to create a threaded server which can hold a database connection open without the complexity of, say, Zope, or mod_perl?
-russ

I don't know if it's good for you, but probably you should take a look at Zope.
--

> You also don't get the benefits of the group calendaring, tasks, scheduling.... need I go on?
PHP3 , Zope , ... need I go on?

Most of the large players have either built their own tools or contracted with integrators to have tools built for them.

Platforms such as Midgard (based on PHP) and Zope (based on Python) make it radically easier to develop such tools.

There also are any number of open-source Slashdot-like environments such as Squishdot; some browsing around in Freshmeat.net will churn them up quickly.

It's an open source web application server and it would make the job you're referring to a snap.

Some sites which use Zope:
www.zope.org
www.technocrat.net
appwatch.com
www.codecatalog.com

It's an open source web application server and it would make the job you're referring to a snap.

Some sites which use Zope:
www.zope.org
www.technocrat.net
appwatch.com
www.codecatalog.com

It's an open source web application server and it would make the job you're referring to a snap.

Some sites which use Zope:
www.zope.org
www.technocrat.net
appwatch.com
www.codecatalog.com

Contrast this with Zope: Browse the UML model for ZODB, and you'll find a DB class, a Connection class, a Transaction class, a Persistent class, but no DiscussionForum class or ForumPosting class. That's because it's one of the very most bottom layers of Zope. You wouldn't put tires on a gas tank, would you? OTOH, browse the UML model for the Zope Portal Toolkit (it's in the file), and you will see things just like you're talking about. I agree, however, that Zope needs more high-level apps built on top of it. We're hoping the community continues to contribute Zope products and we're obviously working on a few as well :-)

probably the most patently questionable statement that mr. greenspun offers is that ACS operates on a much higher abstraction/application level than zope. i'd like to hear some justification of that statement as i think that its quite opposite.

The main point here is that ACS and Zope are, in many ways, apples and oranges: At the heart of ACS is a set of integrated data models that backend a variety of applications, e.g., discussion forums: there's a users table, where information about actual users of the ACS-backed site is stored, and there's tables that depend on users, e.g., user-contributed forum postings, comments on static pages, etc.

Contrast this with Zope: Browse the UML model for ZODB, and you'll find a DB class, a Connection class, a Transaction class, a Persistent class, but no DiscussionForum class or ForumPosting class.

This contrast doesn't suggest that ACS is superior to Zope. It just illustrates how ACS is different from Zope: Zope does deal with "lower" (i.e., closer to the computer) things like databases and object persistence, whereas ACS deals only with "higher" things like human beings and the things they say.

The term "higher" in this context is not meant to be a measure of quality. Rather, it refers to location in the stack of software layers that comprise a database-backed web app. ACS focuses on what goes into the "database" part of the problem, and Zope provides (among other things) a solution for the "-backed web app" part of the problem.

I don't think there's any reason why you couldn't take data models from the ACS and build a web app on top of it using Zope, instead of AOLserver.

I realize that this level of analysis is simplistic, but I hope that it helps to clarify Philip's statement about levels of abstraction.

in what way is ACS easy to program as a framework, and how well does it abstract away those details to those altering the application, designers/content managers? looking for some answers.

One of our programmers in Berkeley (Karl Goldstein) actually developed a content management system in the course of building a site for one of our customers: PogoPet. Karl's system is in use on a number of ArsDigita-built sites, and our plan is to roll it back into the ACS this summer.

Server Busy

The server is temporarily busy. Please try again later.

David E. Weekly

The document is actually very good and covers many of the advantages of Zope over the infrastructure that ACS is built on (AOLserver, Tcl, Oracle, ACS utilities). There's a "killer app alert" for Squishdot.

Weirdly, it doesn't seem to touch on Philip's arguments regarding the need for concurrency and insanely high performance.

Take a look at ArsDigita File Storage. They spend a lot of time analyzing their competitors!

The document is actually very good and covers many of the advantages of Zope over the infrastructure that ACS is built on (AOLserver, Tcl, Oracle, ACS utilities). There's a "killer app alert" for Squishdot.

Weirdly, it doesn't seem to touch on Philip's arguments regarding the need for concurrency and insanely high performance.

Take a look at ArsDigita File Storage. They spend a lot of time analyzing their competitors!

Zope Vignette

There are others(possibly asp, coldfusion, jsp, etc...), but these are the ones I know a bit about.

The following information sources are usually a bit more productive that the current manuals:

The Zope Documentation Project

The mailing lists

The How-Tos
--

The following information sources are usually a bit more productive that the current manuals:

The Zope Documentation Project

The mailing lists

The How-Tos
--

The following information sources are usually a bit more productive that the current manuals:

The Zope Documentation Project

The mailing lists

The How-Tos
--

Squishdot is not a port of the slashcode, it's a clone of some of the basic Slashdot functionality that was produced long before the recent release of the slashcode. It currently lacks features such as self-registration, member pages, post ranking, member pages, etc.

Nevertheless, it is an astonishingly useful product, and can be set up on a working Zope installation within about 5 minutes.

Some sites running Squishdot include:
Technocrat.net
Gnotices, Gnome developer News
70South
eBiquity.org
91.266A - Numerical Methods

and my own FIAWOL site.

There is also a big project underway to build a 'Portal Toolkit' (PTK) for Zope. You can find it here. The features of the PTK include self-registration, member pages, wizards for member contributed content, a review mechanism for member contributed content, multiple integrated sources for user authentication, most portal content 'discussable', etc.
--

After having slaved away for several weeks building an per/xml based content engine (Kumera), I started having a look around to see what else was out there, and got suddenly depressed.

The only saving grace was that is Australia, the cost of running a dedicated server is way too high, and so there is still space for a cgi-bin perl based system.

Although you may not be interested in all of this, I'm doing it for my own sanity and clarity ...

In my wandering I have found ...

http://slashcode.com/ - the content engine that slashdot is based on. Runs in mod_perl (or cgi-bin I guess), very sofisticated. Has daemons that run to collect content for the slashboxes and everything else we know and love about slashdot.

http://www.zope.org/ - not sure, I think it's a python based application server that has some content systems built around them, including (just to confuse you) http://squishdot.org/ which is the slashdot code ported to zope (I think)

http://frontier.userland.com/ - is a news system/engine that has a thing called manilla, http://manila.userland.com/ which is a front end to editing and so on. Frontier isn't free or open source, but very popular.

http://java.apache.org/jetspeed which is a portal based engine built on top of turbine which is an applicate framework for building applications. There is a content engine and discussion group system that are developed by someone else, who are expecting to open source the discussion groups, and provide source and binarys for a low cost of the content engine.

And there are a few more application systems, which are not exactly content management systems as such, but could be used to build some ... like cold fusion, active server pages, java server pages, php3, and the list goes on and on and on ...

The more I look there more there is ...

Netscape 6 beta 1 is but the first branded Mozilla browser. It is based on Mozilla, as Stronghold and Red Hat Secure Server are based on Apache. It adds features, has it's own version of the UI (which is completely replacable, not just the pictures on the buttons)

Whatch out for more browsers based on the Mozilla core. Mozilla itself is aimed at the developer, but there will be 'easy' versions, kids versions, embedded versions, etc. Long live Mozilla!

You got it wrong last time with all the fuss about a discussion on security related bugs in bugzilla, instead presenting it as a decision. Please get your journalistic facts straight.

Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

Maybe if we had a few more details on the type of project you're working on we'd be able to better reccomend some stuff. You mention a web based project. Pyra might be a good one to take a look at. It lets you set up a tree like hierarchy assigning tasks to multiple users and set different permissions to modify items to different users. Pyra is in beta and I've had one glitch with it though. From Webapps comes ITeamWork and MediaLot. I haven't checked them out but they look promising. You might look at Zaplets. While heavily hyped, this looks a little too consumer oriented to me. The PHP Projects site mentions some task management systems. You could probably easily customise these to fit your needs. Zope might also be worth checking out if you want to customise something. Their Squishdot (Slashdot clone) is easy to set up and might be appropriate for your needs. And there might be other more appropriate Zope modules available for project management.

Digital Creations is doing smashing as consultants with their open-source package, Zope.

In fact, opensource is working well enough for them, they just announced that they will open-source the Zope Enterprise Option, a package they used to charge a minimum of $25,000 for.

Digital Creations is doing smashing as consultants with their open-source package, Zope.

In fact, opensource is working well enough for them, they just announced that they will open-source the Zope Enterprise Option, a package they used to charge a minimum of $25,000 for.

I never claimed that ASP is all about VB, or even that all VB programmers are on the level of trained monkeys. It is possible to do serious work with ASP, and I am sure some people do this. However, this is the norm, not the rule.

Most ASP development is done by cheap, marginally skilled VBScript developers glueing together technology that is beyond their true comperehension. It is possible for a skilled programmer to use VB as one of the tools in his toolbox, but such a programmer would be very exceptional in the VB crowd.

The main facts of my original statement remain.

1. The average ASP developer is significantly cheaper thn the average developer for most other web development technologies.
2. Regardless of other merits of various web technologies, this difference alone is enough to make the price taq of something like Chili!ASP insignificant.

I said nothing in my original post about, and I do not personally believe that, MS technologies are inferior to all linux has to offer.

I never even claimed that all linux options are superior to ASP. I did mention Zope, but that is not a linux-only technology (Zope works on windows just fine). You shouldn't be so quick to make harsh accusations and call names, unless your purpose was to troll (I choose to assume you aren't a troll, just unbelievably thin-skinned, self-rightous, immature, and paranoid enough to invent attacks that I never made.)

If you had actually read as far as my sig, you would have noticed that VB developers aren't the only ones I piss off.

When I worked for ChiliSoft (just an internship in QA) I spent a lot of time thinking about this.

Chili!Soft's primary target has been corporations who want to use VB/VBScript monkeys to churn out pages, then serve up set pages on rock-solid unix servers. The cost difference between good developers that know things like PHP, Perl, or Python and dime-a-dozen VB junkies is enough to make the cost of Chili!ASP negligable.

Chili!Soft is not claiming that ASP is the best technology, they only recognize that

• VB developers are dirt-cheap
• and
• people have good reasons for not wanting to run MS Servers in production.

Would I buy Chili!ASP for a home machine? No. Would I choose to use Chili!ASP if I was starting a web project from scratch? No - I would probably use zope. Would I encourage a company with web aps in ASP (or a large exisiting VB team) to switch from Windows+IIS to *nix+Apache+Chili!ASP? Definitely!

People that are agitated over the skinning thing have No Clue(tm).

It's not a skin. You can do a completely different UI with XUL. The age of applications over the web has finally arrived.

The point of having their own wiget set is that I, the web developer, can finally have my web site look the same no matter where it runs. If you're tired of motif/Win widgets messing with your careful layout, you know what I mean.

One example of how it's not a skin is the Zope Mozilla Initiative, a project to turn Mozilla into an IDE for zope. Let's see you turn WinAmp into a mp3 editor!

With mozilla, you can develop an application, implement the UI in mozilla, and poof! You've got a web application that can run on almost every OS out there!

This IS revolutionary, certainly moreso than anything from Redmond.

Try the Zope web app server. Zope turns all docs/folders into objects, assigning permissions is at its core. Just give users who log in permissions over a certain level of the document hierarchy and they're collaborating. A little knowledge of XML or Python and you can wing it with finesse. ITrack is a collaborative issues tracker. And Squishdot is the discussion widget with the look and feel of your favorite flamefest. The Zope community is rapidly extending and support is getting better with improved documentation and user's groups.

Try the Zope web app server. Zope turns all docs/folders into objects, assigning permissions is at its core. Just give users who log in permissions over a certain level of the document hierarchy and they're collaborating. A little knowledge of XML or Python and you can wing it with finesse. ITrack is a collaborative issues tracker. And Squishdot is the discussion widget with the look and feel of your favorite flamefest. The Zope community is rapidly extending and support is getting better with improved documentation and user's groups.

Try the Zope web app server. Zope turns all docs/folders into objects, assigning permissions is at its core. Just give users who log in permissions over a certain level of the document hierarchy and they're collaborating. A little knowledge of XML or Python and you can wing it with finesse. ITrack is a collaborative issues tracker. And Squishdot is the discussion widget with the look and feel of your favorite flamefest. The Zope community is rapidly extending and support is getting better with improved documentation and user's groups.

One of the most encouraging trends in OSS developments these days is the development of new tools allowing people to communicate while minimizing strife and misunderstanding.

• SourceForge

  Sourceforge is a centralized depot where tools like CVS, mailing lists, and such are to be found, one problem is that sf does not have anything like a moderation/review system in place to discriminate the good the bad and the ugly.

• Zope

  Zope is a publishing environment that allows pretty much infinite flexibility and supports many different styles of communication.

• Wiki

  Wiki is more a paradigm than a piece of software. The best explanation of Wiki is that it's a section of serverspace that anyone can edit at any time. Totally insecure, extremely open, it's very much public cyberspace. One of the surprising things about wikis is that even though they are very open the level of discourse is usually quite high...

What's generally lacking so far in Opensource is a widely used means of prioritizing projects and recruiting resources. But that may not be such a bad thing, after all experimentation is what drives the whole ball of mud forward, eh?

"WildCat BBS software has used the technique of wildcard DNS entries to track incomming tcp/ip user 'sessions' for years. Simple case of prior art."

Abused tracking is, of course, but this is such a clumsy method that it is not likely to spread.

Indeed, I'm not too concerned about this being patented since the URL http://bgfv3wz0.software-patents-are-bad.com/ has no obvious advantage over http://www.software-patents-are-bad.com/bgfv3wz0/.

Your software becomes much simpler, you don't have to rewrite every URL.

You can use absolute URLs within your site (/About/ instead of ../../../About/), so you can reuse navigational elements throughout your site at every level and it reduces the chance on errors.

Not exactly prior art since it wasn't that long ago and in any case toth doesn't log, but still that makes it obvious in my book. Same problem as ever though: what's "obvious" to a bunch of web developers who read RFCs is not generally "obvious" to bunch of patent clerks who read the National Enquirer

And who says you get the images from the [sessionid].website.url server? You can still serve your images from www.website.url. And any other static content, so caching works on that just fine. Actually, this is what slashdot does. Just look at the source of this page, and pay attention to the URL of every image.

Fact is, e-commerce needs state. State can be maintained by using cookies or using session IDs in the URL. Up until now this was done using the path portion of the URL, or the query string. These people figured out you could use the hostname as well.

With all three these techniques you loose cachability of the object the URL points to, but this will not prevent a good site desingner from using static, constant URLs for static, constant content.

As much as I am opposed to software patents, the idea is a clever use of the available resources and techniques. And I don't think there is any prior art.

If you want to fight this, you will have to come up with better arguments. Have a look at "Against Software Patents" for some amunition. Note that this document is 9 years old, so the amunition might be a bit weak. However, some good public momentum behind it might just get something done.

Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

I'm currently using Zope, It's open source, completely free for commercial or non-commercial use and is simply frickin amazing.
Do yourself a favor and check it out.

Those looking for wisdom in the battle for better interfaces should take a look at Zope's management interface. I'm not saying that the interface is very good right now (some would say it's horrendous), but the approach taken by Digital Creations is very good.

Zope is a collection of objects and each object provides its own management user interface. Because everything is browser-based, interfaces to new classes of objects are relatively simple to create.

Zope's roles and permissions features are not easy to master. They are complex, and the user interface doesn't make them much easier to understand. But the user doesn't have to learn a set of keywords and read a HOWTO to set up the permissions. All of the instructions are onscreen.

Thus Zope does not try to present everything in such a way that the user instantly knows what to do in every situation, but it does reduce the need for a HOWTO or a help file. That is the goal we need to achieve: require no external references.

I know many of you are adept at configuring Apache, but I would bet there are very few of you who don't need to look at the reference manual each time you change httpd.conf with a text editor. (Yes, the embedded comments help, but they don't solve the problem.)

Both the Mac GUI and Zope (and to some extent Windows) have had a small advantage in the GUI department: developers are forced to provide a GUI interface for everything the program might do. Those who are working on improving the Linux GUI might try something drastic: rm -f /usr/X11R6/bin/xterm

Zope falls under the same category. Almost nothing in Zope is configured via text files. Every object has to provide its own management interface, or the user can't use it at all. It is a sound design philosophy.

Notably, the SWAT tool for Samba provides a very effective interface as well. Samba includes some extremely strange options. The interface hides the advanced options by default, but they are easy to turn on. Every option includes a link to its description in a help file. SWAT eliminates the need to break out a reference manual while providing access to every odd feature of Samba (AFAIK). So SWAT is another example of a tool that simplifies the interface without removing any advanced features.

The best way of dealing with complexity is to simplify and limit features to the essentials. JavaScript, graphics, fancy layout, etc. all can present an bottomless hole for time and bandwidth.

Another thing to realize is that the relational database you are using is probably one of your biggest bottlenecks. Relational databases are slow. MySQL is actually one of the faster ones, but that's because it doesn't make a lot of the guarantees or provide a lot of the features that a "real" relational database provides. You can get a lot of performance from your relational database by tuning it, but ultimately, the architecture and functionality itself present a limit. If speed is of the essence, consider using dbm, plain files, or memory mapped files (Apache has several "databases" internally, and that's its approach.)

For a single person project, Java is probably not the best implementation language. It really shines for multiprogrammer projects. You may find that Python, PHP, or Ruby are better choices. Perl and Tcl are also widely used, but they are also the oldest of the scripting languages and have a lot of rough edges and clunkiness. The performance of all of them is excellent when used as server plug-ins. Perl and PHP have by far the largest libraries and toolsets.

Some of the packages I haven't used but that look interesting are the following. Enhydra takes a much better approach to dynamic HTML than most other packages, I think. Erlang / Eddie address scalability, reliability, and clustering in a really clean way (but you have to learn a new language). Zope I think has a lot of good ideas, but I'm not sure I'd use it for a large server.

Most load balancing solutions use some kind of network routing hacks. That's efficient, but can be a pain to configure. However, there is now a load balancing module for Apache that works as a proxy; that's probably also worth looking into.

The Coda file system is a free, next-generation AFS; while I'm not sure Coda is mature enough yet to be used in heavy-duty applications, systems like it help with scalability by replicating files automatically and have been used on some really large web sites.

I would stay away from commercial "application server platforms". They often are mostly repackaged open source software, and they are expensive and complex, and while they claim to be general, they are also usually created with fairly specific commercial applications in mind ("shopping cart", etc.). I think those kinds of packages are worthwhile for corporate developers that work with large teams of programmers and need consistency, documentation, training, and support.

So, to recap, this kind of stuff is still a lot of work and it seems like you are ahead actually. But there are a lot of proven open source tools available that have been used on really big projects. There are also a lot of open source developments coming around that may make this kind of project a easier.

In an n-tier environment (web server, app server, database server) all the application server really does is:

• maintain a persistent pool of connections to the DB;
• maintain state in a stateless protocol;
• help separate application logic from display logic
• perhaps assist in transaction load-balancing

I have worked with a half-dozen commercial application servers and the all work equally well for anything I've built. Since there are 2 excellent open-source app servers, Zope and Enhydra, I see no reason to spend a dime on a commercial product unless of course their proprietary RAD tools are something you can't live without (trust me: you can live without them). Still, none of them beat AOLServer pointing to an Oracle8i DB set up for transactions.

The only thing you really need to remember in transaction processing is that the network is the bottleneck.

• If you can shorten the network path, do it.
• If you can design your app so you send the fewest number of bits across the network, do it.
• If you can use the filesystem apache is sitting on to serve "dynamic" content, do it.
• Make everything you can a static file, even if you have to generate it from a database overnight.
• And cache everything you can.

The reason I restrain is that my source code might be worth a lot of money someday. If I GPL it then people can get it free. Isn't there a lot of profit lost in open sourcing?

There are companies which did exactly this, opening there former proprietary software. Two very well known examples are Mozilla and Zope. There is a good description how Digital Creations went open source with Zope and what their fears were and why they still did it.

- Stephan.

The reason I restrain is that my source code might be worth a lot of money someday. If I GPL it then people can get it free. Isn't there a lot of profit lost in open sourcing?

There are companies which did exactly this, opening there former proprietary software. Two very well known examples are Mozilla and Zope. There is a good description how Digital Creations went open source with Zope and what their fears were and why they still did it.

- Stephan.

The reason I restrain is that my source code might be worth a lot of money someday. If I GPL it then people can get it free. Isn't there a lot of profit lost in open sourcing?

There are companies which did exactly this, opening there former proprietary software. Two very well known examples are Mozilla and Zope. There is a good description how Digital Creations went open source with Zope and what their fears were and why they still did it.

- Stephan.

Now the Everything engine is very flexible, and Slash lets you get a lot done, there's really nothing out there like Zope for Perl.

At the risk of a shameless plug, let me just say that that's why i started Jellybean.

--

Erm.. sometimes it is A Good Idea (TM) to give away the most prized possession of a company. But only when it will make them more viable and profitable.

Take my employer for example, Digital Creations. In November 1998, they were a product company, with a great product. A Web Application Server that, if only the customers would see it, was much better than what all the multi-billion-dollar companies were offering. Not many people were listening to the tiny voice of this company though.

Then a VC convinced them to make that product Open Source, and switch to services, solutions build upon that product. Now, over a year later, the company is hiring like crazy, O'Reilly has started funding the company, and the product is making great inroads in the marketshare of those aformentioned multi-billion-dollar companies. Going Open Source is paying off.

Anyone of you ever heard of Zope? Let's just say that 85% of all people I asked at LWE did. Long live Open Source, long live the free messengers.

Not that this little story has any impact on Transmeta of course. They have a solid business model based on a product that just would not benefit from going Open Source. Their voice is being heard, they are making the inroads just like that. And not that Metcalf cares. Change is just scary, but he'll get over it.

Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

Erm.. sometimes it is A Good Idea (TM) to give away the most prized possession of a company. But only when it will make them more viable and profitable.

Take my employer for example, Digital Creations. In November 1998, they were a product company, with a great product. A Web Application Server that, if only the customers would see it, was much better than what all the multi-billion-dollar companies were offering. Not many people were listening to the tiny voice of this company though.

Then a VC convinced them to make that product Open Source, and switch to services, solutions build upon that product. Now, over a year later, the company is hiring like crazy, O'Reilly has started funding the company, and the product is making great inroads in the marketshare of those aformentioned multi-billion-dollar companies. Going Open Source is paying off.

Anyone of you ever heard of Zope? Let's just say that 85% of all people I asked at LWE did. Long live Open Source, long live the free messengers.

Not that this little story has any impact on Transmeta of course. They have a solid business model based on a product that just would not benefit from going Open Source. Their voice is being heard, they are making the inroads just like that. And not that Metcalf cares. Change is just scary, but he'll get over it.

Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

What do you mean, inflated version number?

Netscape Open Sourced version 5, but never released it.

Mozilla is build partly on version 5, but has lots of new code. Netscape 6 is based upon the results of the Mozilla project. Sounds logical to me.

Martijn Pieters, Software Engineer
Digital Creations, Creators of Zope

Look at cleaner examples such as Zope.

You should not forget about Squishdot (runs on top of Zope). While it still has a long way to go, it's quite usable. It runs on technocrat.net, if you want an example.

Don't be afraid of the merge. Just look how the History is being writen.

Linux exists despite MS, and today IBM adopted it.
The AOL/TW merge is only the Cathedral side of the mass-media production/delivery game.
We, /.ters should promote and write the Bazaar side of the History
We are the Reporters, Analists and Consumers of our own information and news. Just grow the base of the users of this /. model and promote it among other non Geek communities.
Every /.ter in a non technical company should compromise to create an internal company bulletin board. It's quite easy.
Go Zope grab your copy of zope in the desired flavor (Unix,...etc) and install the squishdot product. You will have an instant bulletin board that any one could use.
Let's help people to create, comment and use the information they really want.
Let's make true "News for NON Nerds Stuff that matters"

I understand both sides of the issue. It is Rob's code. No law says he has to release it. But, out of respect for the community in which he has become such an icon, he could at least be honest about it. If the code is heading for a close source, then say so. If it is truely going for open source, give us a target date. We have heard 'soon' since mid-1999 at least.

Odviously, Rob, you are taking a bit of flack for this, and you must see that inflamatory remarks like the '24 delay' comment don't help the situation, though I understand your frustration.

I also understand that you probably won't give us an target, but you may find yourself catching a bit less flack if you give us a bit more than just an undefined 'soon'. Give us a plan with some meat. Will it be released under a standard GNU? A modified GNU? Will we have to link to Andover as well as Slashdot? What features will be included and what won't (moderation, PGP keys, karma, etc.) in the initial 0.4 release? Give us some positive discussion on the topic instead of just voicing you frustration.

Here is some info on slashcode help and alternative code bases:

The slash-help mailing list is here. This list discusses the original slashcode 0.3, as well as non-Malda flavors of slash and the pro's and con's of each.

A forked version of the 0.3 code is availible here.

PHPSlash is being developed independently of the Malda crew. It can be had here.

A Zope version called Squishdot is also availible.

DOINS is also an alternative slashcode base, though I've not worked with it personally.

I've seen some comments about slashsites not giving credit to Rob and Co. Please remember that these other versions of the code exist and are completely seperate. So, just because a site looks like slashdot doesn't mean its using Rob's code. That said, most of the non-0.3/0.2 sites are run by fans of Slashdot and so have links to it. Squishdot for example.

The slash-help mailing list is here. This list discusses the original slashcode 0.3, as well as non-Malda flavors of slash and the pro's and con's of each.

A forked version of the 0.3 code is availible here.

PHPSlash is being developed independently of the Malda crew. It can be had here.

A Zope version called Squishdot is also availible.

I've seen some comments about slashsites not giving credit to Rob and Co. Please remember that these other versions of the code exist and are completely seperate. So, just because a site looks like slashdot doesn't mean its using Rob's code. That said, most of the non-0.3/0.2 sites also have mention and links to slashdot. Squishdot for example.

Here are my questions:

So far slashdot is the only site I know of that IS a self-moderating community. If other code bases begin creating moderation/metamoderation models, are they in danger of a Malda patient on metamoderation/karma or the self-moderating community concept? I think I can guess at the answer, but it would be good to have some official verbage on this from Rob.

Those of us actively working with slashcode 0.3 etc. understand the nature of beta and don't expect a 1.0 release. 0.4 would be fine even it is doesn't work, like 0.3 didn't when it was released. We will gladly fix it. Given the long period of time that 0.4 has been promised (check here for a post by Rob back in June about releasing 0.4 and here is one in August), the fact that the slash community is not likely to forget that promise, and the fact 0.3 has rather silly Y2K problems (see the slash-help list archive for fixes) will you, finally release SOMETHING or admit that the Slashdot code is in reality and practice close sourced beyond 0.3?

Would you please add a link to the slash-help mailing list mentioned above (http://projects.is.asu.edu/mailman/listinfo/slash -help) to the www.slashdot.org/code.shtml page?

If it hasn't exactly shown in this post, Rob does great code. My compliments! You have us hooked and we want more! -Temple