Ok... I realise that most open source projects usually start with one persons idea, they develope that idea into an initial code base, release it to the public and then try and build a community around it.

What would happen if you took an already existing community of like minded developers and started planning an open source project around it?

Ive been thinking about this for a while, and thought it was high time I threw it out there. What if we, as a well established community, pulled our resources to develope a framework and eventually a cms?

I know there's alot of people here that wouldn't have the time to throw in massive hours, but that is the beauty of community driven developement, you dont have to do it all yourself. Personally, I dont dev for work. I love to program, and do it almost as a full time hobby, Ive plenty of hourse to throw into something like this.

Here, we have a huge community of developers all sharing the same language, all with different specialitys and skill levels, anyone could be invlolved on some level.

I know there are hundreds of these projects already in existence, why reinvent the wheel? Well, I just feel that we could do a better job, and those of us involved from the beggining would gain alot of knowledge and experience.

Im positive if we pooled our collective resources we could build a damn fine framework.

It could be started by simply talking about the design. People come in, post there opinions on how best certain aspects could be built and we all feed off each others ideas. We could then, through this discussion, devide the framework into groups. eg; database abstraction, user authentication etc... Then people could decide on what group they would initially like to help maintain.

Of course, without an initial code base, the whole idea could be a little difficult. We would, probably, out of these groups need to nominate a person to develope the initial code base. I believe that once there is some initial code in place we could go from there.

Anyway, I guess the subject is now open. Before we talk about any specifics I would like peoples opinions on the concept itself. Is this achievable? How could we make this happen? Is anyone even interested?

Anyone?

    Well, to be honest, I'd have to have a little more motivation than just a framework / CMS. I'd like to think that with so many PHP programmers, and several being rather experienced and qualified to be considered as a serious developer, could come up with some pretty rocking PHP app's.
    I do agree with the general idea that everyone should have an input as how the general design should go. Though, the only draw back I can see is that someone has to be giving either a veto or go ahead on an idea. Several people trying to draw up the same program design could be rather hectic, chaotic, and well, messy. But let's just pretend that we'd all be able to agree upon a final original design plan, and we can all set down some rules and regulations concerning naming conventions and all the other tidbit things that truly define whether or not a project will be successful.... I think it might actually work...
    Splitting it into seperate groups would of course be required, but then again, someone has to be to oversee what's coming into the project as each programmer submits work. So there'd have to be a few senior designer/programmers. And of course, each senior designer would have to do the general layout for their section's programs, so each programmer could have a gneral guidline to go off of....

    but yeah, is it possible? I'd give it a yes. How much interest? Not sure... like i said... Everyone's made or worked on a CMS somewhere... but ya never know, depends on how much input is givin to the project.
    and that's my 2 cents. Probably worth less 😉

      It is achievable, but you'd need a hierarchy of coders to say who does what, and who has "final" say about issues.

      In thinking aloud, Anon should be our leader since it has the most posts...

      It is feasible. I think it would be neat to have a lot of experienced programmers working with inexperienced to help them learn. Whether it's on a CMS, Support Ticket System, or BBS any work with experienced coders is worth it to a newbie.

      There would need to be a lot of concessions as to who is better for what, and a lot of humility and humbleness to say I'm not good, or that's not good, re-work it. I can't see anything getting off the ground if we as a community of coders on the project can't criticize eachothers work.

      Feasible? Yes

        Thanks to both of you for your input, you both make some really good points.

        Several people trying to draw up the same program design could be rather hectic, chaotic, and well, messy.

        This is where you would need some sort of group leader to actually initiate the first build of there particular part of the application after some corrispondence in regard to the design goals. Once the initial code is in place, the others in this group would mostly be responsible for improving on and extending this initial code.

        you'd need a hierarchy of coders to say who does what, and who has "final" say about issues.

        This is the same in any open source project. There would always need to be someone where the buck stops. Someone actually capable of making design descissions and enforcing them in some way.

        I guess the main problem with trying to start a project with an already existing community and no base code is that it may actually be too community driven. Im no open source project expert but I have read the catheadral and the bazzar and it appears to me that most os project communities dont actually talk too much. They simply log in to the projects cvs, get a recent copy, code what they want, then upload it.

        The idea of actually starting a project from nothing does seem quite different to any other approuch ive read about. Somehow though, It does seem possible. Im sure there would be hurdles, but Im sure these could be overcome.

          Great idea, I'll be in for what I can be. However, if the fate of nullBot is anything to go by...

            Right, so we've declared it feasible.

            Now: what type of project to persue...?

              I'll say I'm in for coding and even design but my schedule is such that I have no idea what I'm doing from week to week...so far this year has not taken a deep breath yet.

                Just another 2 cents:

                Personally I think there are more than enough frameworks and CMS's out there... one area I see lacking is e-commerce shopping carts. Of course I'm biased because I'm basically submerged in it, and I'm a huge fan of Zen Cart. But really the only major contenders out there are osC and ZenCart, imho, and it would be nice to see some alternatives. Zen Cart is great, but there are a few things I would have done differently, and a few features that seem to be lacking. Just a suggestion, of course.

                I've got my hands in too many pots to be a real active coder but I'd be glad to offer suggestions on what would be required.

                  Good one E.

                  I'm dreaming of finding a project that will pay me to build a cart that rides on top of any site that uses javascript/ajax at the frontend and certainly php behind the scenes. Installing it would be easy as heck and users could create the actual store part in a billion different ways (only their order link(s) would matter). Oh yeah, the php backend could handle that too I guess.

                  😉

                    But wouldn't it be good to build a framework that supported any type of application? cms, cart whatever. I was thinking if you built the base framework in such a way that you could simply build application modules that applied the actual functionality.

                    I have a few design ideas in mind, but Im on my way to a wedding today. I'll be back next week to post some more.

                    Its good to know there is some interest out there.

                      thorpe, I have been watching your quest for the CMS grail but it is just not out there and simply can not be done. Web sites are not general enough for their to be a perfect CMS solution. The reason I learnt PHP was to build a CMS and for over 3 years I've been playing around with them. Forever trying to "crack it" but I don't think it is possible to have a complete CMS solution for all types of websites, modules or not.
                      Lucky me as to be working on a project right now that will require a CMS 🙂, I have an idea to tackle a major problem CMS's have. I'll let you know when it's complete.

                      Elizabeth I know exactly what you mean. I just used OsC, never again. Both applications are SO out of date it makes you want to cry.

                        Another small/large project would be a global DBM script. The idea being that you'd select (either drop-down or via config file) which service you're using (mySQL, Postgres, MS SQL, Oracle, Sybase, IBM DB2, etc.) and with it, you can completely control the database (users, permissions, tables, and databases). It'd be like a merger of phpMyAdmin, phpPgAdmin, and the mySQL Admin and pgSQL Admin tools into one script....

                        Each part would be small; however, all together it would be a huge project. Of course, it should be PHP 4 & PHP 5 compliant (as I know I'd love to use it)....

                          Think that would just be over complicating things bpat1434. Maybe not for all, but at least MySQL, PostgreSQL, Oracle and perhaps MS SQL? I don't think anyone would use all DBMS's on a regular basis, if they did they'd probably be insane by now :o

                            True, but i was thinking it was more to the point of being THE buckshot for Database Management tools. If you want a web interface, use this. You don't have to utilize the DBs, just know they're there.

                              but i was thinking it was more to the point of being THE buckshot for Database Management tools

                              hmm... but then you'll either end up implementing multiple database handling scripts under a unified interface (PDO might help), or end up supporting only the lowest common denominator.

                                Jason Batten wrote:

                                thorpe, I have been watching your quest for the CMS grail but it is just not out there and simply can not be done. Web sites are not general enough for their to be a perfect CMS solution. The reason I learnt PHP was to build a CMS and for over 3 years I've been playing around with them. Forever trying to "crack it" but I don't think it is possible to have a complete CMS solution for all types of websites, modules or not.

                                Jason (and Thorpe and anybody else I recognize around here) if you are curious to see what I've done - as I'm about to do a second beta round with this thing - send me a PM. I've come up with some pretty simple ways to handle multiple language sites (workflow) , allow the creation of many types of sites all in one system (which has alot to do with the form the url's take) and plenty of permissions and groups etc stuff. Next week, the new revamped version goes into official action on it's first site. 😉

                                And I agree...one cms will never solve every problem. CMS are human processes. The software should assist in the process.

                                Edit: What the heck...I haven't put up any pics for some time...here are some more (the person consulting on the interface with me says I can't change anything about it - but I'm determined to make it look better when I get the chance):

                                >> Directoy of plugins (php functions), css and javascript files
                                >> Template code preview (Includes has this too)
                                >> Galleries (and Books) main page
                                >> Pages edit - showing multiple language management
                                >> Pages main - note the languages at the right and also the various publishing statuses
                                >> Admin - menu management (easy as pie to customize and move around stuff (you can create your own top level tabs as you see fit too)
                                >> Admin - module management (NOT COMPLETED AT THIS TIME)
                                >> Users - permissions for sections (for module writers making custom permissions things is just an array element away
                                >> Home - group forum using workgroups (because sections can be moved around people don't have to use or even have this module) The calendar updates via Ajax so you can see if there are group events posted to the forum but it's not supposed to be a full blown calendaring system - everybody has apps for that.

                                Oh yeah, because I'm on a roll here, the publishing of things is centralized. So, developers could create more and new Content modules that would all share the same information regarding publishing pages and whatnot - it's slightly redundant but it solves all the problems of having multiple content streams.

                                Because I need to build a shopping cart for my own purposes soon I'm going to integrate a backend into the system. My idea to float the cart on a layer above content (only showing items if items are selected) has been done by a friend already and I'm hoping to add this stuff to it as well (but like me, he doesn't want to release it until he's cleaned the code up). 😉

                                  I've been mulling an idea for a while now. I've been calling it Cicada.

                                  Instead of Yet Another CMS, or Yet Another Shopping Cart, I was thinking of an application for constructing bespoke sites with shopping carts, or with blogs, or with member logins, or with whatevertakesyourfancy.

                                  Oh, and it also constructs the CMS for the site administrator to manage it.

                                  It would also provide an environment in which the L&F of the site could be assembled - abstract templates that can be filled in with bits&bobs to customise them for a particular site.

                                  Cicada users could write additional modules (both backend functionality and front-end UI) that they can then deploy in the sites they create.

                                  One thing about its operation. While under development, everything runs out of the database. All there is in the development site document tree are the binaries (graphics, etc.) and three files:

                                  1. A generic Cicada driver script. This is the same for all sites under construction.

                                  2. A configuration file. The potential complexity suggests XML as the format for this, because it lists all of the modules the site uses, along settings for all of their options, and all of the other thingies that fully describe which Cicada assets are used in the site.

                                  3. An .htaccess file that inclues a big mod_rewrite chunk for turning human-friendly URIs into URIs that reference the driver script with a nasty great querystring to say exactly which page in which state is to be displayed.

                                  There are two databases. One is the database the site itself is using (user list, article storage, etc.); the other is the Cicada asset database. All of the site's code comes out of the asset database. That's HTML, CSS, Javascript, PHP, the lot. The driver script susses out which assets to pull and which code to eval() based on the querystring it's been given.

                                  Yes, it will be slow, but this is just the development phase - it allows for sweeping changes to all aspects of the site's construction pretty much on-the-fly. Once the site is built, and the client is happy and signed off on it, the Big Friendly "Publish" Button is boinked, and Cicada does a load of bumping and grinding, pulling all the assets that are used out of the database, filling in the templates with site-specific stuff (company logo/homepage link goes here, AUP text goes here...) pulling all the code out and replacing the database lookup/eval steps with an include() (or even inlining the code) ... and then (optionally), as the pièce de résistance, writing all those files and the site's own database to the live server. The mod_rewrite chunk is a lot smaller since in most cases now the page being asked for physically exists instead of being written on the fly by the driver script.

                                  Job done. NEXT!

                                  Needless to say, the configuration file and client-specific assets are retained in case the client wants changes. As the Cicada asset library is updated and resources improved, those improvements can filter out to client sites as and when they're redeployed.

                                  Unlike some similar apps I've seen, a Cicada-published site does not need a Cicada server after it has been deployed; it's a fully self-contained site, so the client isn't locked in to a relationship with the publisher that built the site to keep hosting it (it's nice to have the relationship, but it shouldn't be on the basis of a "leave me and you'll suffer" threat). The client could in theory go to another Cicada-using publisher and get them to do more work, or even to a publisher that doesn't use Cicada, who would have to do changes by hand (such tinkering however voids the manufacturer's warranty.) But that's only in theory. In reality, the publisher may have used any number of in-house modules (one of the points of distinction between one Cicada user and another), and the deployment process, during the course of extracting code, would be inlining and optimising throught the whole show (a trivial example: all those instances of $CONFIGURATION['short_company_name'] have been replaced by "IniTech") as anything that is generic because it varies from client to client is replaced by whatever is specific to this client would make the resulting code somewhat scary for a human to mess with (and even someone else using Cicada would have trouble, since they wouldn't have the configuration file the original publishers have for the client, let alone any in-house assets that were used. If they want them, they'll probably have to pay for them.)

                                  Sounds similar?

                                    Weedpacket wrote:

                                    I've been mulling an idea for a while now. I've been calling it Cicada.

                                    Instead of Yet Another CMS, or Yet Another Shopping Cart, I was thinking of an application for constructing bespoke sites with shopping carts, or with blogs, or with member logins, or with whatevertakesyourfancy.

                                    Oh, and it also constructs the CMS for the site administrator to manage it.

                                    Sounds similar?

                                    Going back...many years now...this was the idea. After I worked for two failed cms companies/systems that didn't believe in 'flexibility' I started making this. Over the years, and with client projects that forced this thing to get better (and my skills) this is what I've been trying to do.

                                    I've always disliked how I needed separate systems to manage things - why couldn't they live in one place under one roof and possibly even work together? Many systems have plugins/modules but mostly these just apply to front-end tricks. A module for me is a back-end addition that lives on it's own and can be used/integrated elsewhere.

                                    But yeah, trying to find the common things about building 'sites' such that it could be possible for a web app to build whatever is the mission.

                                    It is a little tricky defining the table for a common publishing table but by sticking to a few rules it's totally possible to put it all in one place and/or cache, build includes (real ones), etc., from it. My mod_rewrite file is only 6 lines but I do have to process URI type stuff more than I'd like - next week I'll be trying to find ways to reduce this.

                                    The person who first gave me instruction in PHP actually managed a system like Cicada (and more loosely mine) for a public agency. They had a monster site that was driven by ASP - many years ago, this thing was very difficult to use (once a week it would take a work day for it to update the entire site - everything had to be republished).

                                    I'd love to see how it could be possible to utilize xml and reduce the number of tables. Currently, I have over 20 managing everything. A section like Pages (webpages) requires help from Sections, Templates and Users to get the job done. Because I have this centralized publishing table ANY content module can get involved. The module defines the form the output will take (which is really helpful with stuff like shopping carts).

                                    Additionally, I can compose new modules based upon other modules - right now I'm making a 'Projects' module for a client that utilizes Galleries, Content, Tagging and a Blog module (which is just a simplified and more specific Content module). It will, obviously, create project pages that are rich with content. Plus, they require three languages...

                                    Certainly, I'd like to find a way to cache everything and even have some caching control over a busy site, but this will be a job for another day...or when a site gets slammed and I don't want too look bad. 😉

                                      vaaaska wrote:

                                      They had a monster site that was driven by ASP - many years ago, this thing was very difficult to use (once a week it would take a work day for it to update the entire site - everything had to be republished).

                                      This isn't the same as one I saw some years ago, is it? 🙂 The painfully slow lumbering (even just for serving pages, let alone updating) was the principal motivation behind my idea for having it write out everything and a custom CMS to update it with once as a self-contained site that no longer needed the publishing engine behind it. That and the fact that it means the site doesn't need to be hosted on the publisher's servers.

                                      One advantage I can see that XML provides for config is in its namespace support. Since different modules have different configuration requirements, it appears that you could have a distinct DTD or schema (I'm thinking schema, because then you get to control data types) for each module, and then you can mix them together into the one XML file, importing them into their own namespaces as needed. So that you could, for example, write a configuration file for a Projects model that imports the Galleries, Content, Tagging, and Blog DTDs.

                                      <project xmlns="http://www.cicadapublishing.org/modules/project.dtd"
         xmlns:blog="http://www.cicadapublishing.org/modules/blog.dtd"
         xmlns:gallery="http://www.cicadapublishing.org/modules/gallery.dtd">
<blog:blog>
...
</blog:blog>
<gallery:gallery base="/gallery/">
  <gallery:exhibit base="polar/" name="Over the Pole">
    <gallery:item src="images/item10.jpg" alt="Map of the route"/>
    <gallery:item src="images/item11.jpg" />
    <gallery:item src="images/item12.jpg" />
  </gallery:exhibit>
  <gallery:exhibit base="workplacehorror/" name="This is Not Your Job">
    <gallery:item src="images/cubicle14.jpg" />
    <gallery:item src="audio/comeinSaturday.mp3" alt="Threatening phone call #1"/>
  </gallery:exhibit>
</gallery:gallery>
</project>

                                      The other thing that XML is suited for is when the configuration data has a treelike/recursive structure: a <setting> might contain a <name> element, followed by either a <value> element or one or more <setting> elements. (I'm pulling this example from the Mozilla sources as well.)