Slashdot Mirror

Normally I'd consider those "Yet Another.." posts trolls, but I think there is something to be said about this.

The source to Slash hasn't been released in quite a while; it seems slightly fishy that preaching the joys of Open Source gets Slashdot and Andover a lot of money, but the source isn't actually being released. Is this a strategic move for Andover?

If so, it's pretty stupid. Slashdot functionality has been emulated many times over. My personal favorite is SquishDot, a plug-in for Zope. I don't see any competitive advantage to not releasing the source. It's not like releasing the source is that much more work for Rob and crew; we know it's being worked on because of improvements in Slashdot itself...

A lot of people might respond "If you don't like it, leave. You get what you paid for." But this is a web site held by a publicly owned company; we get bombarded by the ads and click through on the banners and generally keep this site funded pretty well. You'd think that

1. in the face of consumer demand for the source (and yes, we are consumers whose click throughs fund slashdot and andover), and

2. in the face of the open source ideology that slashdot promulgates, and


3. in the face of the fact that there is no strategic advantage in delaying the release to Slash because there are so many workalikes

you'd think that Slash source code would be released.

That having been said, I don't particularly mind if the source isn't released because Rob et al are taking their sweet time due to programmer-endemic laziness (as opposed to andover policy and other conspiracy ideas ), but it would be nice to hear status reports on the matter at the very least (e.g., "01-03-2000: Did nothing.") :-)

just an opinion..

I don't think anybody's mentionioned Python yet. Without extensive knowledge of the other alternatives, all I can say is that with a little care PyApache works for me. It's much like usual CGI in use, with some tricks like a dictionary for each Apache child process.

There's a different implementation of the same idea (embedding the python interpreter) called httdapy, I think, that's a little deeper into Apache interface-wise; I seem to recall it would work with Zope, too. That project is a "web application server" done in Python, if you haven't heard of it yet.

2) Tools and a development environment to access coporate databases. Data is the life blood of business. MS makes it easy for developers to get at databases. Linux does not. Not surprisingly MS has made COM objects to access all sorts of databases (I am not talking about the silly data control here either).

Right now PHP and, to a smaller extent Zope, are leading the way to dbms access. And it's not just for the Web, either. PHP is more than able to be a standard application scripting langauge capable of performing the duties of a number of previously entrenched languages/tools. You'd be downright shocked by the number of SysAdmins who are changing their perl scripts over to PHP.

For Internet B2B applications, PHP is very hard to beat.

---

Designing a heavily database-driven site which uses URLs without query strings is very possible.

One of the unofficial mottoes of Zope is that it gives you "URLs you can read to your mother." This sets it apart from other app servers like Vignette Story Server, et. al. and many home-grown Perl solutions.

In Zope, there is really no such thing as a static page. Straight HTML pages are stored as Python objects in an object database and are rendered on-the-fly just like any other object.

You don't need to tack all that stuff on to the end of your URL. Really.

Is it even possible to index dynamic pages? They don't really exist until the page is generated. Perhaps the best thing to do for sites that want to be indexed is to make sure they have a plain, vanilla index.html page that contains relevant keywords?

It depends on what technology you're using to generate the pages.

Zope sites for instance, are totally dynamically generated, even those pages that would normally be static. But the entire content of the site that's stored in the ODB is traversable via 'normal' URLs. This means that search engines can easily index your entire site.

Note, however, that this only works if you've taken care to expose your content via links. If you've delibarately hidden your content behind a search interface (and you can still do this with Zope), then your site will be no more indexable than any other dynamic site.

Version 2.0.1 is here. I don't know what site you went to, but I've been using this for a couple of months. In any case, Zope.org appears to be the site to hit for all things Zope.

...and throw away machine cycles, maybe PHP _is_ cool. But if you rather have an organized, object oriented web development interface, with multithreaded persistent database connections, a standalone web server, plugable modules and no overhead per call, try Zope. All the great new sites use it, like AppWatch, Technocrat and iMacLinux. Why? How about going from drawing board to full featured site in 2 weeks? And please don't mention the PHP + MySQL combo, the MySQL license sucks. OpenSource rules, I don't care about the rest.

The Zope web site
lists serveral Zope Hosting Providers. Ask one of these ISPs to install the Squishdot product and you can have
have a ready-made slashdot up and running in

The Zope web site
lists serveral Zope Hosting Providers. Ask one of these ISPs to install the Squishdot product and you can have
have a ready-made slashdot up and running in

The Zope web site lists serveral Zope Hosting Providers. Ask one of these ISPs to install the Squishdot product and you can have have a ready-made slashdot up and running in no time. If you need something more complex you can buy the premium service and install your own custom built products.

The Zope web site lists serveral Zope Hosting Providers. Ask one of these ISPs to install the Squishdot product and you can have have a ready-made slashdot up and running in no time. If you need something more complex you can buy the premium service and install your own custom built products.

Without denegrating C-T's great work on the Slashdot software, I'd like to point out there's an Open Source weblog at squishdot.org. It's in quite an early state - looks rudimentary next to Slashdot, but it has a real Open Source Definition compliant license and releases are done reasonably often. Future versions will probably incorporate ZDiscussions, a component of Confera which is distributed on the zope web site, and of course the whole thing is built on Zope.

Thanks

Bruce

My NT4/IIS4 PII/266 server was handling an average of 9,000 requests/hour with spikes of 20,000 requests/hour and handling as many as 1,000 email messages/hour - not average, but spikes. Does that count as heavy? I needed to reboot that machine about every 3 months.

No, that does not count as very heavy. Go over a couple of forums to the answers from the person who switched the Royal Family over to Linux to get real life judgement of how to handle a somewhat heavier load.

And no, you should not need to reboot every 3 months.

Would Apache have handled the load? Most likely but the point is NT and IIS are more than capable of handling as much as you have bandwidth to support.

Exactly right. Virtually anything can do the basic job. Now look at licensing costs, stability, and security. While NT and IIS can do it, various variations on the Unix theme with Apache can deliver more value for less.

BTW do yourself a favour and try ZOPE...

Cheers,
Ben

Only I want to take it even further. First off, let me reference two previous posts on SlashDot: 'Its the API's Stupid!' and 'Again: Its the API's Stupid!'. In those posts I made the case for developing an API that was both an Open Source Component development/delivery/runtime system and a set of standard Components built with/for it. Quote from those posts:

"We need a fast, simple, powerful and complete Open Source solution for component based development. An API (preferably a cross platform one) that you can write code to in any of the most popular languages. And it must have a reference implementation that is open source with a GPL license. It should be highly Object Oriented and should provide base objects for every major Design Pattern. It should front-end the OS so completely that you can write a new OS which directly provided the relevant API's (making it a kind of Meta-OS). The API itself should be open and there should be a standards committee that isn't loaded with representatives from the big companies. Plus, no-one is penalized for producing a non-compatible version (other than the fact that compatible versions would probably receive a greater market share)."

Also Quote:

"I have been working on my own for some time to develop the beginings of such a standard. A kind of hobby for me. And I know there are plenty of people out there who will claim such a thing already exists in (choose one) PERL, Python, Smalltalk, Gnome or some flavor of the month. I don't think any of those things meet all the criteria of the environment I want to see, but I can state one thing rather confidently... Until we pull together a produce such a thing the Open Source movement will have a lot of difficulty competing against Sun and Microsoft in the Business Systems space. "

One person sent me a pointer to Bamboo, an Open Source project to develop a component runtime system (partially using Mozilla code, which is cool). Others have referred me to CORBA and even ZOPE. Personally I think all of these things are good (although CORBA may be too heavyweight). But none of them go as far as I would like.

Although I want to see real code as well, I think the process should start the way any good development process should start: With a good design. With an architecture. I am currently calling this the 'COA' or 'Common Object Architecture'...

In one of my design documents I describe it this way: "A shared set of class and interface specifications that may be implemented in any language and/or with any distributed object methodology. The COA is a Specification, a Platonic Ideal - any implementation of the architecture is coupled to the COA only to the extent to which it correctly exposes the interfaces of the architecture. The intent is to create a standard system workspace for programmers to use that transcends operating systems and programming languages. Furthermore the COA is intended to facilitate the creation of distributed applications where the objects may reside on any system on a network, but look like they are local to the calling application."

Then, once the design is complete, we throw it open for development. Much like a protocol, anyone can develop both open and closed source versions of the COA. Of course I expect the Open Source versions to get more use...

And these versions might be developed for any platform and in any language because one basic part of the COA would be a split of the class definitions into two types: Native and External. Native classes have standard method calls that may be directly implemented in whatever language/object environment is being used. External classes may only be accessed through a common messaging interface defined in the COA Messaging library.

This means that Native classes are generally 'synchronous'. They return control to the calling code immediately, allowing them to be implemented as 'In-Process' and 'In-Thread' with the calling code. In most cases Native classes will be fairly small grained 'tool' classes used as components in building larger, more functional, objects.

External classes are extremely large grained 'Actor' objects that expect 'prompts' and execute 'behaviors'. They operate asynchronously, the only way that calling code can know they have completed a requested function is when they return a message indicating this fact. Although an External class may actually be implemented to run in the same process space and even in the same thread space as the calling code they function as external servers where the calling code is the client. In many cases the calling code may only be connecting to a lightweight message interface class which front-ends an External class running on another machine entirely.

These two types of classes exist to provide an opportunity to "Have our cake and eat it too." The Native classes may be bound at compile time (for those implementations that support it) and will operate with the least possible amount of interface overhead. Plus they make it possible to create implementations of the COA in environments that do not provide for multi-threaded programming. Meanwhile the External classes allow for disconnected operation and execution across system boundaries with the least amount of overhead possible.

Sometime soon I expect to set up a discussion group on this topic. Anyone interested? Email me and let me know...

Jack

I don't want to seem antagonistic or anything, and this isn't a flame, but I think you missed my point entirely. Read my post again.

I *do* see the value in accessing my files/apps/data from more than one computer. I *made* the point that I *am* doing web applications for precisely the reason you mention. I am developing a web application and content management framework entitled Iaijutsu (in case you missed all the links. :) ). I *do* access the web applications I write using my Palm III, and am hoping to do so with my Sprint PCS phone. I wasn't talking about desktop applications. I am *for* web applications, but not in the way SmartWorker does it.

The point I was making about another layer on the web is this: Why, specifically, another GUI toolkit? That's just another tight binding system between logic and presentation.

If I understand correctly, SmartWorker can be made to present application differently with a set of 'rendering engines'. I noticed engines for WinCE, DHTML, etc...

So, if I want to present the results of my application logic differently, I have to code another engine, right? Or, I have to reconstruct the code comprising my GUI layout logic, right? It requires someone with a knowledge of Perl to change the look & feel of an application in SmartWorker. In general, to change the presentation of my application in SmartWorker, I have to rework part of it's logic that has been devoted to manipulating the GUI toolkit. Is this correct?

Now, I while I also appreciate that perhaps I can separate my application and a SmartWorker GUI into modules with an established interface between them, my question is: Given the fact that we have a machine readable user interface specification format that is much simpler than Perl (i.e. HTML), why circumvent it by layering another toolkit on top of it and adding complexity and tight coupling to the application? I'm not saying HTML is the best, but it's well known and there are plenty of tools to build it.

The alternative I presented in my last post was this: A system like Zope or my Iaijutsu uses a template language to add flexibility to an HTML document to allow the presentation of the results of an application, mostly independent of the application itself. As long as the application generates the same well-defined data structure, the application logic is free to change, and the presentation is free to change-- independently of each other.

More practically, what this means is:

1) I'm the Perl guru, I write the backend code that churns through the database and returns some row data. 2) Upstairs is a graphic design geek who makes the pretty skins for my application. 3) The guy next to me is the HTML Production Artist who takes the designer's images and processes them into GIFs and HTML with Macromedia tools. He also takes my description of the template language and writes the simple looping tags that fill in table rows from my database results.

With SmartWorker, I think it might go more like this:

1) I write the Perl logic. 2) The designer hands the interface design image to the Production artist. 3) The production artist makes some GIFs, but no HTML, and hands that to me. 4) I write some Perl that lays out the tables and buttons and etc, as close as I can to the original Photoshop design. In this stage, we can't use anything like a nice Macromedia tool to generate a page because it's all done in Perl GUI toolkit calls.

Now, the client asks for a radical change, but luckily enough, it's just cosmetic-- the application inner workings are still the same.

With Zope or Iaijutsu the process goes like this:

1) I don't have to do much at all, because my part (the application) has remained the same. 2) The graphic designer reworks the image. 3) The HTML Production Artist imports the image into a Macromedia tool, cuts out all the images again, and recreates the HTML template using the methods I gave him. Job done.

With SmartWorker:

1) The designer reworks the image. 2) The Production Artist gives me another pile of gifs. 3) I toss out the Perl module I wrote to layout the GUI, and start over writing more Perl code to try to match the new GUI.

In summary, what's the problem here? For one, if any change is made to the presentation, we *all* have work to do because changing the SmartWorker GUI required Perl expertise. And for another, not only do we all have work to do, but we can't use all of the standard tools we have for HTML page layout.

So, with SmartWorker, our process of delegating work to each other's specific skill sets is broken, and the tools that make 5 minutes' work out of making a 'skin' for the application in HTML are lost.

I don't want to seem antagonistic or anything, and this isn't a flame, but I think you missed my point entirely. Read my post again.

I *do* see the value in accessing my files/apps/data from more than one computer. I *made* the point that I *am* doing web applications for precisely the reason you mention. I am developing a web application and content management framework entitled Iaijutsu (in case you missed all the links. :) ). I *do* access the web applications I write using my Palm III, and am hoping to do so with my Sprint PCS phone. I wasn't talking about desktop applications. I am *for* web applications, but not in the way SmartWorker does it.

The point I was making about another layer on the web is this: Why, specifically, another GUI toolkit? That's just another tight binding system between logic and presentation.

If I understand correctly, SmartWorker can be made to present application differently with a set of 'rendering engines'. I noticed engines for WinCE, DHTML, etc...

So, if I want to present the results of my application logic differently, I have to code another engine, right? Or, I have to reconstruct the code comprising my GUI layout logic, right? It requires someone with a knowledge of Perl to change the look & feel of an application in SmartWorker. In general, to change the presentation of my application in SmartWorker, I have to rework part of it's logic that has been devoted to manipulating the GUI toolkit. Is this correct?

Now, I while I also appreciate that perhaps I can separate my application and a SmartWorker GUI into modules with an established interface between them, my question is: Given the fact that we have a machine readable user interface specification format that is much simpler than Perl (i.e. HTML), why circumvent it by layering another toolkit on top of it and adding complexity and tight coupling to the application? I'm not saying HTML is the best, but it's well known and there are plenty of tools to build it.

The alternative I presented in my last post was this: A system like Zope or my Iaijutsu uses a template language to add flexibility to an HTML document to allow the presentation of the results of an application, mostly independent of the application itself. As long as the application generates the same well-defined data structure, the application logic is free to change, and the presentation is free to change-- independently of each other.

More practically, what this means is:

1) I'm the Perl guru, I write the backend code that churns through the database and returns some row data. 2) Upstairs is a graphic design geek who makes the pretty skins for my application. 3) The guy next to me is the HTML Production Artist who takes the designer's images and processes them into GIFs and HTML with Macromedia tools. He also takes my description of the template language and writes the simple looping tags that fill in table rows from my database results.

With SmartWorker, I think it might go more like this:

1) I write the Perl logic. 2) The designer hands the interface design image to the Production artist. 3) The production artist makes some GIFs, but no HTML, and hands that to me. 4) I write some Perl that lays out the tables and buttons and etc, as close as I can to the original Photoshop design. In this stage, we can't use anything like a nice Macromedia tool to generate a page because it's all done in Perl GUI toolkit calls.

Now, the client asks for a radical change, but luckily enough, it's just cosmetic-- the application inner workings are still the same.

With Zope or Iaijutsu the process goes like this:

1) I don't have to do much at all, because my part (the application) has remained the same. 2) The graphic designer reworks the image. 3) The HTML Production Artist imports the image into a Macromedia tool, cuts out all the images again, and recreates the HTML template using the methods I gave him. Job done.

With SmartWorker:

1) The designer reworks the image. 2) The Production Artist gives me another pile of gifs. 3) I toss out the Perl module I wrote to layout the GUI, and start over writing more Perl code to try to match the new GUI.

In summary, what's the problem here? For one, if any change is made to the presentation, we *all* have work to do because changing the SmartWorker GUI required Perl expertise. And for another, not only do we all have work to do, but we can't use all of the standard tools we have for HTML page layout.

So, with SmartWorker, our process of delegating work to each other's specific skill sets is broken, and the tools that make 5 minutes' work out of making a 'skin' for the application in HTML are lost.

Zope is extensible in Python. The ACS is a large package of tcl code that accesses the AOLserver API (AOLserver is now also free as in speech). Both encourage a style of programming that is more maintainable than Perl. If you knew Perl already, I strongly doubt you'd have asked your question. That's actually a good thing -- the same things that make Perl great for simple one-shots make it tough for novices to maintain. Python (and to a lesser extent, tcl) is a great deal cleaner.

I didn't mention Java or Jserv -- there is a package called JetSpeed which the Java-Apache group has put out, but my initial reaction was that it was very slow. Don't take my word for it, though -- take a look and decide for yourself.

Don't be an idiot and lock yourself into Yet Another Uncaring Vendor. You can get support for Zope or the ACS direct from the developers (Digital Creations or ArsDigita respectively). If you choose to use mod_perl and postgres, you still can get professional support. With Lotus you can look forward to servers that don't write log files, proprietary APIs, flat file "databases", and other such niceties.

Don't buy into it.

I'm looking at a similar project and I think Zope and Squishdot (with bunches of customization) will fit the bill!!

http://zope.org

http://squishdot.org

You need to get and install Zope first then add
Squishdot as a module. Works grand and straight out of the box but you need to decide you need Zope first as this is a strategy level thing really.

You need to get and install Zope first then add
Squishdot as a module. Works grand and straight out of the box but you need to decide you need Zope first as this is a strategy level thing really.

The CEO of Digital Creations, the Zope people, did a talk at the Atlanta Linux Showcase pretty much describing this sort of thing. They looked for a venture capital firm that they felt they could trust; surprisingly, it was actually the VC people that suggested releasing Zope as free software.

The big point here is that it would be wise to contact a company that produces free software that has IPOed, and see what firms they have dealt with. Such firms are likely somewhat better choices to deal with than firms that haven't done VC work with "free software" companies.

In the case of Digital Creations, the VC firm was the Verticality Investment Group.

In the beginning, there are obviously not many VC firms that "grok" free software; those few firms that do, and get extra business as a result, will doubtless be noticed by those that are "later adopters."

Check out Zope from Digital Creations. Its a completely Open Source eCommerce development kit. I'm not affiliated with DC in any way, but I have been using Zope for the past few weeks and I can tell you that it totally rocks. Its one of the most impressive pieces of technology I've ever seen. And yes, DC will be happy to sell you varying levels of consulting service and support.

You may also want to check out ArsDigita, a relatively open source toolkit based on an Oracle backend and AOLserver frontend. ArsDigita is an excellent company run Phillip Greenspun. They'll also be quite happy to take your money for hand holding and whatever else you need.

Finally, before you jump onto the eCommerce bandwagon, check out Web Tools Review, an excellent site run by Greenspun et al.

Personally, I've been developing Cold Fusion applications for about 2 1/2 years now, and I think Cold Fusion is one of the greatest products the Win32 server arena has ever seen. Crashes from IIS are not too uncommon, but I don't ever recall Cold Fusion crashing or even hiccupping in the least. If you are having problems with Cold Fusion stability on your server, you should probably take a closer look at the installation.

Also, if you are looking to implement some kind of fail-safe, I would highly recommend Zope over PHP3. I've used Zope as well, and I think it far outperforms PHP3 in just about every aspect I can imagine. You can check out Zope at its website.

Also, as someone else said, keep on Allaire's heels-- they are supposed to have Cold Fusion for Linux out by the end of the year.

Good Luck..

Perhaps you should consider zope. It has a very cool database-connection, is written in python and runs nearly everywhere (unix, nt)

While it may not exactly be Notes (yet). Check it out. We use and like Notes but have infact moved some sites and work onto Zope It has most of what you've just mentioned including relational database connectivity an indigenous object database and a drop in product called Confera for discussions. It's a true application server that is managed through the web. It's mostly written in Python so it's easily extensible. Zope is moving fast and getting features and products added almost daily because the company that created it Digicool open sourced it. It may not do exactly what you want but I'm sure it will still be something that you would want to look at.

There is a Zope component that connects to an IMAP server to provide a web oriented front end that can be accessed via HTTP, XML-RPC, and even FTP. The most common configuration is HTTP (via a fairly functional but very minimal web forms based interface).

I jokingly call it NotMail. Since being hired by the authors of Zope, I have not be able to pursue it to hard core, but Python, is as most of you know, is vey easy. Most of the core is done, there would just have to be some improvements made to get it to work with the new Zope version, 2.0b1, some threadsafing issues (2.0 is fully threaded) and of course, some cosmetic changes to the HTTP interface.

For an example of a Zope powered site, check out Technocrat.net.

Don't forget Zope from your list of application servers.

It has a couple of advantages over the others listed:

• It's Open Source
• It's not a bloated-pig-from-hell
• It's not just a really dodgy windows port (or has CF been properly ported to Unix now?)
• It's Open Source
• and it totally rocks.

AFAI understand it, those restrictions do only apply to modifications of the Zend engine, not to scripts in general. As far as you don't link with the Zope code, this shouldn't be a problem, if you apply the analogy to Qt. 'Linking' would probabably mean 'building compiled modules', which you could not distribute without source.

One reason for choosing the QPL could be that the GPL is
a) not compatible with (many) other Open Source licences and
b) unlikely to be defensible in court.

But, if you need a python-based web publishing environment, you could as well take Zope

With python, the object is the way, the truth, and the light. Let no man cometh unto his data save through the object. In perl, OO is an option, not a requirement.

Hmm? You can quite happily store your data in interwoven dictionaries, lists, and tuples if you like, and never write a single class. If you want to talk about classes being a requirement, talk about Java.

With python, you cannot generate C code to compile into an a.out.

With python, the pattern matching is not tightly integrated into the language. It is merely loosely bolted on, which introduces inefficiencies and quoting clumsinesses.

True, but it also means you can leave it out if pattern matching isn't of interest to your application domain. People who want to run massive numeric simulations, build virtual environments, or run a large online role-playing game may not care about processing text. (Coincidences are funny things; while checking the third link, I went to reference.com and was startled when my search pulled up Python code on my screen -- someone forgot to make a CGI script executable, I suppose. reference.com is an application that does care about text searching, I would imagine.)

The greatest problems with regexes in Python 1.5 are:

1. Parts of re.py are still written in Python, not C, and are therefore slow. Fixing that is on my list for 1.6.
2. PCRE doesn't do a lot of optimizations and analyses. Mostly this is because the compiler doesn't build a parse tree and traverse it, but instead tries to construct a string of bytecodes in a single pass.
3. Unicode regexes are an open issue at this point. I've been casting longing glances at the regex engine in Mozilla, which does build a nice parse tree and supports Unicode, and hope to work on splitting it out into a separate library.

With python, you cannot determine your calling context, nor behave differently dependent upon the same.

With python, writing an eval string is a pain in the royal butt due to the insane whitespace problem.

With python, you have no equivalent to Apache's mod_perl.

Squishdot is better than Slashdot. And it's written using Zope!

Oh, wait...

An excellent technical (though not a very technical) book. Greenspun's interest lies in creating online communities that are useful and vibrant enough to survive for long periods of time. Greenspun understands that such utility doesn't arise from trivia such as micro-tweaked HTML or the latest hyped plug-in; instead, it comes from permitting people to connect in ways that aren't possible without the connectivity and information accumulation made possible by the Internet and by database software. I highly recommend this book, and its principles will probably guide my future plans for the MEMS Exchange site.

An online version of the book is available, and is definitely worth a browse; the photographs will look better in the printed version, though that probably isn't reason enough to buy the printed version. Reason enough to buy the book, though, is simply to encourage such an enlightened approach to Web design and to freeing a book's content.

It's refreshing to see a computer-related book that concentrates on technical opinions, instead of just how-to details. I skipped over the AOLserver code, since Zope would be my choice for an implementation environment (some of the Zope Portal Toolkit ideas seem inspired by Greenspun's book, in fact), but that doesn't materially affect the important ideas of the book, which relate to nurturing online communities. It's not platform-specific in that way; while Greenspun has his preferences for Tcl and Oracle, he repeatedly emphasizes that the specific tool used is of secondary importance.

> [A] company may believe that exclusive access to
> a piece of proprietary software provides the
> company with a competitive advantage. For
> example, a microprocessor-design company might
> embed considerable experience and research in a
> computer program to improve the quality of CPU
> designs. They might quite rationally believe that
> if they gave that software away, their
> competitors would use it to improve their own
> processors and take business away.


This is the case of a "trade secret". It is a very limited case, which applies to a tiny sector of in-house software. ESR does make reference to this sort of case, when discussing Zope. Zope is a Web-publishing kit which was open-sourced at the suggestion of investors in a Web design group. The investors believed (correctly) that the group's value was not in their software, but in their people. While the example of Web designers does not map directly to chip designers, it does at least show that ESR considered this case much more extensively than you claim.

It's possible that such a case as you suggest could arise. However, do you really think that chip design is so automatable that the algorithms embeddable in software create more of the value than the designers do? Or that chip designers have produced a revolution in expert systems, capable of replacing their own knowledge with stored-program knowledge? I doubt it. Stored knowledge is static; the rapid pace of chip design is kept up by continuous design revolutions. And those come from people, not programs.

My current project, the MEMS Exchange, is looking for good developers, and placement services aren't much help, because the people we've interviewed often seem to be clueless. (Write me if you'd be interested -- we're in the DC area, and are a research-oriented non-profit.) We've had horrifying experiences where a candidate's CV looked good, but it all fell apart at the interview, where we found they couldn't write pseudocode for reading a file line-by-line. If we knew a person could at least design and code reasonably, because we knew they'd maintained a non-trivial software package, that would be a good foot in the door. Similarly, a while back Digital Creations got a bunch of new employees, hiring practically everyone who had done a significant project using Zope. This is another good reason to hack on free software; it can earn you a reputation, and that reputations can lead to better offers and more interesting jobs.

I used to be really into MOOs, not because of the social-interaction stuff but because they're such a neat computing metaphor. Everything's stored inside a database, including the programs that manage the database! And everything's hierarchical, so scripts can make variables globally accessible. Very cool stuff.
In my opinion, a MOO should just be a programming language with a database back-end, and everything else written in that language. That way, you can use the database for anything you want- a MOO, for instance, makes a really great scriptable web server (not quite as good as Zope, though). And you can use it to serve basically anything you want. Instead of making just a Java MOO, why not make an extendible application platform, with a database that can execute code, which happens to work particularly well for serving text-based virtual reality worlds?

Don't forget Zope

Zope can handle large volumes -- see their page on case studies -- several online newspapers use it on a commercial basis for high volume/high traffic situations.

They also have a chat board product (with threaded discussions) that you can plug in. Zope also has an indexing facility built-in that automatically gives you a search capability.

As for editing, Zope has just implemented WebDAV which allows for distributed authoring and versioning. You can try webdav editing with IE 5.0 and Zope to see if this fulfills your needs.

You manage the entire website with just a browser 99.99% of the time, so you don't have to worry about deploying client software.

It also has an ACL like hierarchy based user access/security interface so you can fine tune the capabilities that you give your users to access or modify your data.

As for converting your back issue articles, it maybe just possible to use ftp to transfer all your back-issue html files into zope. Zope has a builtin ftp server that can be used to transfer files between your ftpclient and the webserver's internal object database.

If this is not what you want, you can probably create a program to do that for you. Its all open source, so the code is available for your modifications.

It also has a dynamic community of Zope advocates that are very helpful in bringing newbies up to speed. They have an active mailing list you can join.

In terms of commercial support, Zope is backed by a commercial company, Digital Creations, who originally created the software as proprietary closed source and saw the light, turned it into open source. If you want commercial support or do it quickly you can hire those guys.

Now, the negatives (not entirely). Zope uses a scripting language named DTML (document markup template language) -- it's like HTML which is easy enough to learn but also subtle enough that it can take a while to become an expert in. Also, while not required, it would help a lot if you know Python, because that's what its written in.

I would urge you to try it out or at least check out the web site( www.zope.org) because I'm certainly impressed by it and all the people I know who started using it are also mightily impressed by it.

If you're looking for a free, cross-platform, open-source Object DB, take a look at Zope. It's actually a complete object-oriented web application server, but as it is open source, you could pull out the ODB part for your own use. It's written in Python, with a little C++ for performance critical code.

GISA (General Internet Servelet Architecture) will also be a boon here, assuming it ever gets off the ground.

-- Eric

There are some testimonials and users listed on the Zope site. Principia, the closed source forerunner of Zope, was shipped with some 5.x version of Red Hat on the CD of commercial applications. I'm continually meaning to get around to using it seriously, but never manage to find the time.

Anyway, most things can be found on www.python.org. Many people started off with GvR's tutorial; O'Reilly's "Learning Python" book is currently scheduled for release in April.

Java hackers should take a look at JPython, a 100% Pure Java reimplementation of Python that's an astoundingly cool tool for prototyping and testing Java code.

People interested in the Web should look at the recently freed Zope; the documentation still needs work, and lots, lots more examples, but it's also a very powerful publishing system.

Why bash Digital Creations? They've modified their license, changing the attribution from a requirement to a request that can be ignored if you like. DC staff, most notably Jim Fulton, have contributed various things to the Python distribution, which is free software. While the whole attribution thing was ill-advised, and I still think it shouldn't be in the license (why not just leave it in a README?), claims that they're "starting to twist free software" are utterly bogus.

Can I get a witness from the congregation?

Thank God that some one besides the Free Software Foundation is picking up the torch to explain the (IMHO) major differences between OSI and Free Software.

I, too, thought that the OSI was a "good thing". That is until folks like Digital Creations are starting to twist free software in to purely a profit making endeavor. They happen to be the first blatant example, but not the last, I am afraid. (See my letter to the editor for Feb 11, 1999 issue of Linux Weekly News for further explaination.

I share in Bruce Parens belief that

The Open Source certification mark has already been abused in ways I find unconscionable and that I will not abide.