PostNuke

POSTNUKE COMMUNITY CODE OF CONDUCT


PREAMBLE
Your commitment to this Code of Conduct in all Community areas, which shall apply to all forums, chat areas, comments, mailing lists and/or other message or communication facilities designed to enable you to communicate with the Postnuke community (collectively, "the Community"), ensures a positive experience for all our users.

Postnuke, postnuke.com, The Postnuke Project and the Postnuke staff (hereafter referred to collectively or singularly as "Postnuke" or "PN") are not responsible for the content or activities of users in any such Community area.

RESPECTING OTHER USERS
Members of the PN Community shall be obliged to treat each other with mutual respect. Using the Community to threaten, harass, stalk, or abuse other members or PN developers or staff participating in any Community area will not be tolerated.

PN will not tolerate disruptive activity, such as persistent off-topic comments and postings or statements that incite others to violate this Code of Conduct or participate in activities that are not conducive to the well being of the Community as a whole. Registered users must certify that they are over the age of 13, and are expected to act accordingly. This Community is a vibrant and positive place. We'd like to keep it that way.

The PN Community is a place where developers and users can collaborate, integrate and participate in the design and progress of Postnuke and support each other in furtherance of same. PN is not a forum to air your political views. Comments that derogate another member or group with regard to race, gender, religion, age, national origin, sexual orientation, disability or socio-economic background shall be considered a de facto violation of this Code of Conduct and will be dealt with accordingly.

The PN staff will delete posts and comments that do not comply with this Code of Conduct. Repeated violations may result in further action, up to and including banning users from the Community.

<stong>NO SPAM
Please don't spam the Community. Spamming includes sending identical and/or irrelevant submissions to many different forums or mailing lists. Usually such postings have nothing to do with the particular topic of the group or are of no real interest to those on the mailing list or forum.

PN reserves the right to take such action as PN sees fit up to and including removing offensive messages and/or banning a user at any time, with or without notice, from any or all Community areas for spamming.

The Community areas may be used to provide supplemental information regarding your own business (provided that you do not use spam to provide this information); however, the Community areas are not designed to be used as the primary mechanism for operating your business or providing core information about your business. Any use of the Community areas for commercial purposes is solely at your own risk and PN has no liability for such use.
The preceding shall not be construed to prohibit or discourage members from posting links to their own websites where commercial services may or may not be offered. Building web sites is, after all, what PN is about.

ENCOURAGE, DON'T ABUSE
PN's core developers spend countless hours to provide you with a robust content management system. They are not paid for their work. Many of our module, block and theme developers also offer their hard work to the Postnuke Community with no expectation of any compensation other than the satisfaction of creating something that will be enjoyed and utilized by PN users worldwide. Likewise, many of them are not paid for their work. They do not owe you anything, however when you choose to use Postnuke or the modules, blocks and themes that are offered for free to you, you do owe the developers, at a bare minimum, respect for the time and effort that they have spent. Abuse or harassment of developers regarding their efforts or their release timelines will not be tolerated.

YOU ARE RESPONSIBLE
You are responsible and liable for all of your activities while participating in the Community areas.

PN reserves the right to remove at any time, with or without notice, any posting that violates this Code of Conduct.

You are responsible for any actions you may take based on advice or information you receive online. Use your own good judgment when evaluating information provided through any Community area; remember that the information provided could be from people of any age and experience level. The decision to conduct transactions with anyone is your own and you should conduct your own research prior to making any decisions.

UPHOLD THE CODE
In helping to make the Community a great place to meet, collaborate, support and share, you must do your part to uphold this Code of Conduct.

PN reserves the right to immediately terminate or suspend access to any Community area for violations of our Code of Conduct, or at the staff's discretion to deal with situations or behaviors that do not comply with the spirit of this Code of Conduct, although such situations or behavior may not be addressed specifically herein.

PN also reserves the right to amend or change the Code of Conduct at any time with or without notice. You agree to periodically review this document to ensure you are doing your part.

There's a lot of good news - notably that PostNuke has grown tremendously, with an estimated 250,000 installations, and continues to grow thanks to the contributions of tireless and talented developers whose code beats within PostNuke. This popularity is noticeable as one stumbles across more and more sites on the web clearly built with PostNuke - for many sites it's obvious, for others not so obvious because there are some great theme designs out there.

As it stands, such popularity has also attracted many third-party developers to PostNuke, contributing blocks, modules and themes. While the spirit of free (as in 'free beer') software reigns for many contributors of such add-ons, a small community of commercial developers has also sprung up around our favorite CMS - and that's where some of the points of contention seem to come from.

Notably, some of the commercial developers are interested in providing their products in the form of binary-only (protected, and without source) form, in order to protect their commercial interest. These modules are *not* GPL (by virtue of not making their source code available). A veritable outcry has happened, albeit only by a very few, decrying what they claim amounts to heresy.

There are several issues at hand here, all of which we want to address, hopefully to the satisfaction of most, if not all:

- Commercial Products : It has always been our opinion that commercial ventures are encouraged, as they will invariably help strengthen the framework of PostNuke, and in turn help the community grow. Furthermore, commercial ventures will help PostNuke gain additional 'legitimate' recognition, as a serious tool in the field of business, or within the enterprise environment.

It is certainly the right of a developer to choose the way they want to distribute their software and it is your right to place a value on their time and effort, if you so choose. And unlike those few programmers that are independently wealthy, things like rent, food, and car payments don't get made by trading code (at least, not yet).

- 'All-Software-Must-Be-Free' Mentality - While it is certainly nice to be able to freely benefit from another's efforts, the basic reality is there is also (in our opinion) a lot of freeloading in that mindset. The purpose behind free software is to be able to freely trade with other programmers, who you then contribute code to - this worked in the old days within tightly knit programmer communities, but breaks apart as communities grow and more and more users join who have a variety of skills sets. Which means many aren't contributing code, but are looking for tools and resources. However, their contributions can be other valuable things like documentation and support, they can also contribute compensation in the forms of donations, postcards, or the ever popular universal currency, beer. As such, we believe free software is nice (and we will always appreciate anyone contributing generously), but likewise, shareware, donationware, and commercial software have a place that should be respected.

- Open Source Software - There's a big confusion over 'open source' and 'free', as there's a segment of the community that firmly believes if it's open source, it *must* be free. This certainly is not the case, as even the GPL specifies quite clearly products licensed under the GPL can be commercialized. In fact, it's encouraged. The key with the GPL license is only the source code has to be freely and easily accessible. This is both a benefit, but also a liablity for commercial products. On one hand, by making their code available, the community is able to contribute fixes and enhancements back to the commercial vendor - this has benefitted such diverse companies as linksys, TiVO, Apple and RedHat. Likewise, the availability of the source code also stands the danger of making proprietary
technology available to competitors - which is why many other commercial vendors sometimes pick different licenses allowing them to protect part of their technologies.

Still, if something is GPL, it stays GPL - that's why PostNuke will *ALWAYS* remain GPL licensed. There's many reasons why this is so, but the best is we know it is in the best interest of the project, as well as the community.

- Close-Source Contributions - this is the sticking point, wherein developers use the PostNuke framework, and contribute a module or add-on, that does not include the source code, and is distributed in a binary-only manner. Is this terrible? Is this evil? Is this the end of civilization as we know it? Of course, not.

Is it a violation of the GPL? The way we see it, it isn't (if done right - meaning no re-use of GPL code), but most of all, wether it is, or it isn't, IT IS NOT POSTNUKE'S RESPONSIBLITY! Why? Simple, because we cannot control third-party developers and a third-party product does not alter, or affect the copyright, trademark, or development process of the PostNuke Project. The few such products we have seen that fall into this category, target niche or vertical markets - thus, nothing PostNuke depends on.

The final decision regarding any such products or add-ons lies with YOU, the PostNuke community, as a commercial product will only be viable if it is being purchased. If you do not like how a vendor packages their products, if you do not like the way they sell them, if you do not like the prices, or the license - DO NOT BUY THEIR PRODUCTS! You may even take an additional step, and send them a polite letter as to why you will not be a customer, maybe if they get enough of these types of letters, it may convince them to alter their business model.

Finally, what kind of commercial products do we like, or rather, which contributors and developers are doing it 'right'? Two examples come to our minds right off the bat - AutoThemes, and Webvida.

With AutoTheme Shawn has created a nice theme utility with AutoTheme - not only making it easy to design themes, but also facilitating portability of themes among various compatible CMSs. While the 'pro' version of AutoTheme is a commercial product, Shawn makes a free version, AutoTheme Lite, available to anyone who needs it. As such, he gives his customer the option of what they want to use, and how they want to support him. The business model seems to be working quite well.

Webvida's Lobos provides themes for PostNuke, via AutoTheme. The themes seem well-designed, and affordably priced. In addition, many themes are provided at no charge, with new themes being added frequently. Also quite a bit of additional support and contributions in the form of tutorials are being provided by both Shawn and Lobos.

Lastly, both appear to be very active in the community, and provide support to the community, as well as to their users. Undoubtedly, there's value in what they provide, and this is commercialization, done right, in our opinion.

The final decision, as we stated above, on all of this, lies with the PostNuke community, as it is up to you to decide which vendors to support, and which not to - PostNukian Darwinism, so to speak - regardless of what any of us has to say, and certainly regardless of what any activists might feel about these issues.

Finally, to make sure we are clear on this issue, we encourage module developers and theme designers to contribute free and open source software to the community but we have no problem with them offering their products and services to the community as described in http://www.gnu.org/philosophy/selling.html

Since it's not yet legally proven it might be even permissible to release addons under a non-compatible GNU/GPL license providing the addons are not derivatives of existing GPL work. While we prefer to take a 'wait and see' attitude regarding such non-free add-ons, should you feel strongly enough about it, we encourage you to take matters into your own hands, and file a precedent setting lawsuit to prove this matter once and for all. We'll check in with you in a couple of years, okay? (Seriously, the effort of filing such a suit, or even being concerned over such situations is not worth expending - vote with your wallet.)

We hope this clears up some things, at least what our opinions are on these issues - and that's what they are, opinions. None of these are legally binding, or even legally proven, and should not be taken as such. We're not lawyers, and we don't want to be, either.

For what it's worth, here's one of the major shortcomings that our multi-million dollar CMS shared with PostNuke: A data abstraction layer (like ADODB, PEAR DB, or JDBC for that matter) isn't the same as an abstract persistence layer. In a data abstraction layer, the complexity of the specific database implementation is hidden from the developer. A Data Abstraction layer, for example, lets you do things like this:

$myItem = new Article();
$myItem->setName("someName");
$myItem->setAuthor("Michael");
$myItem->setBody("This is an article body");
$myItem->save();

Obviously, there's nothing wrong with that. Nothing, that is, as long as you don't want to change your Article content type. If you ever need to add a new field, or modify an existing field in the Article class (and you probably will), you will need to hunt down all the client code that gets and sets the existing fields, as well as any hard coded SQL, HTML form fields, display pages, etc. and manually add the new field. In a real world system, this could amount to a fair amount of time and energy to make and test relatively simple content item changes. An abstract persistence layer, on the other hand, is something that sits on top of your data abstraction layer and allows you to persist, update, delete and retrieve objects without having to know the details of the specific content item implementation.. Saving a new Article with an abstract persistence layer might look like so:

$myItem = ContentItemFactory::getContentType("Article");
$myItem->mapData($_POST);
$myItem->save();

Retrieving a specific Article might look like this:

$myItem = ContentItemFactory::getContentType("Article");
$myItem->getByID($_GET);
$myItem->render();

To make something like this work is pretty easy in Java, and will probably be fairly easy in PHP 5. In PHP 4, you can do it without interfaces and abstract classes, as long as you're in full control of your API. The key elements are: 1. Look at your content model from the perspective that all persistable content types have basically the same persistence requirements (that is - if it's going to be in one or more DB table, you have to Create/Retrieve/Update/Delete content items - regardless of whether the type is Articles, Banners, Downloads, or Comments, etc.) 2. Abstract out the things that make one content type different from another. In terms of a CMS, the things that tend to differ from one content type to another are the table they're stored in, what the field names and types are, etc. You can easily abstract this "content type metadata", and store it in flat XML configuration files or in a db table. The choice there is pretty arbitrary. Note that once you do this, you open the door for your CMS to be able to manage a new content type called "Content Type". This also allows you to decouple your content management and display applications from the implementation details of the objects they're managing and displaying. 3. Define the rules for mapping metadata into the various parts of the CMS. There are plenty of places that metadata can be used, and once of the most useful is in defining how to generate SQL queries for specific runtime content types works. That's the whole point behind the abstract persistence layer. In postnuke, our modules and blocks shouldn't have to know how to save, delete, update, or retrieve objects from the underlying database (which they don't - the ADODB layer takes care of that). They also shouldn't care what fields are in a particular table or object (which they currently do). The CMS, however, can't persist or retrieve objects without knowing how to do so. Giving this knowledge to the CMS via easily configurable metadata would actually make postnuke worth millions. If the PN community were to implement a metadata-driven abstract persistence layer as part of the PN architecture, it would go a long way toward insulating future developers from some of the most tedious types of changes they have to make - verifying that they "connected all the dots" from the input html form - through the system - into the database - and back again. In addition, it would also go a long way toward making it very easy to add new content types or modify data fields in existing content types. As an aside - you could also apply this metadata-driven abstract persistence layer pattern to:

Define the fields and their attributes to display on content entry forms (fieldname, type, maxlenght, entrylabel, validationRule, etc)

Define what fields to display on content display pages and lists

Define the rules for content management workflow and role based security, etc. Anyway - that's my $0.02 for now. Cheers, Michael

TeamCTF is dedicated to providing news and reviews of team-based online multiplayer shooters like UT, Rainbow Six, FarCry, and HaloPC. The site also boasts a custom pn theme, as well as a revamped login page that includes a dynamic status bar. Feedback is welcome.

If there's any interest in the theme or the login mod, we'll make these available to the PN community in the appropriate pnForum.

Footnote: 1

Anyone who cares about GPL should make their views known about these issues.

Remember, the api would have to be licensed like PHP itself, so projects using it can be licensed any way the owner wants.

If enough people are willing to back me on this, I'd be happy to start up the project somewhere for people to start contributing to.

This could be a good thing for other CMS's too. If a bridge were written for other CMS's, this could be a UNIVERSAL CMS module API!

I think we can all agree that this would be a good idea and we can stop all this bickering about stupid evil legalese documents and get on with some coding!!!!!

Footnote: 1

We will install different modules which have a connection to learning in any way. We hope to initiate a new discussion on using Postnuke for learning purposes - the first and only modular open-source LMS ever developed. We need your support!

Marco (Edunuke Admin)

Footnote: 1