Hello all,

I would like some opinions and start a discussion on the merits of a few thoughts I have about the ongoing progress of Xoops.

The main topic is Module development and it's possible shortcomings and solutions.



In the last couple of years, we've had some rocky moments. Many modules are not supported by anyone and others have changed hands. I will use a couple of modules as examples, but do not wish to ruffle any feathers in doing so.


My opinion is as follows: I wish for the Core Developement of XOOPS put emphasis on the ability for XOOPS to Bridge with other Mature Open Source Software or Include in the core development the continuing support of what would be voted as Core modules for the XOOPS system.

1. The changes in developement team from Newbb2 to CBB, and with all props to phppp for the hard work. But the fragility of continuing development of the module scares me in wanting to use SMF instead since it is supported by a large community.

2. The demise of wf-projects team or other teams (even though modules were sent to the smarfactory team) seriously impacts the future of important modules.



My Solutions:

1. In a perfect world, a Module Development Team of which Core Devs are part of would insure the continuing development of modules proprietary to Xoops. Basically I would see all the separate Teams/cells become extensions of the CoreDevs Team. This concept needs better description but I will leave at that.

2. The CoreDevs integrate and actively pursue and support the possibility to bridge with other software like SMF, phpcollab, SugarCRM, etc... I feel this would quickly permit XOOPS to have very powerful modular components with which to build on. Then you can leave the separate Teams/Cells create the more obscure modules that haven't deemed necessary to create it's own open source project.

Singly put, can XOOPS be expected to create modules as powerful as those created by other open source projects and keep their ongoing development in-house??

Cheers.

Thanks Lance_ for your input.

I agree with your analasys, but not with your solutions. XOOPS is a system built to be modular (it is called Extensible and Object Oriented afterall), and thereby enables 3rd parties to use the XOOPS Core as their development framework of their choice.

Now, you say that there should be 'proporietary' modules that are actively developed and maintained by the XOOPS Core Developers. I think that the Core Developers should (as they are now) create a system 3rd party developers can use to create an endless amount of modules, with ease and with many features.

You see, we (as in the XOOPS community) need to pool the resources available. And the scarcity is defined by the amount of resources freely given to a 'public' task, meaning a task not for personal benefit, but for the benefit of all. Core developers are doing just that, they're not adding the features to the core needed to power their own sites, but are building the public framework that enable others to make modules that bring the features they need for their own sites.

So the core is public development, and modules can be more private.

Now comes your problem. Without modules, the core isn't much use. So you propose to create public modules, a proposition I fully support. But you choose to take scarce resources away from the only public pool we have, that of the core developers. Making their resources only more scarce, which is not good for the progress we all want and like.

We (as in the XOOPS Management folks), feel that we should pool the 3rd party development resources available in a public place (dev.xoops.org), and create a new pool of public resources specifically for this. That way we enlarge the common resources pool, enable progress, and get the results you want to see.

It is a common mistake to assume that if something is wanted, someone will step up and actually do it. The motivation of 'I really really really want it made' isn't the kind of motivation 3rd party developers look for (they often ask 'what's in it for me?'). So the problem that needs to be solved is how can we motivate the 3rd party developers to become part of a public pool of resources. And I think that collaboration and the new development framework is part of that.

Hope this helps your discussion

Herko

I would bet that there are more than a few individuals who would be interested in learning ANYTHING that we could to help out with module creation. I know I am one. I fully realize that it is not an easy process to learn, but are there any resources available for beginners?

Don't forget I said "ongoing progress", of course if you take a snapshot of the organization now, you have 4-5 active Core devs maybe, (I even think I'm generous there ) . The idea is truly to have this number up to 25 in a year or whatever. The four or five doing the major core work and the rest doing liaison with the hardCore Devs in the other needed section, principally the Modules.

I simply do not like the fragility of it all right now, when I take a snapshot of Now. We all know that any CMS/portal system requires a few tools in it. A Forum, Content Manager, Image manager, User manager are the basics of a system so they should be included in the main core outlook.

Now even if most or all core devs disagree with this, them create the ability to bridge with other open source components and you won't have to worry about these important modules, the core will always have it's use, and third party module creator will always have their place in creating the "I need this" module.

I will build also on gestroud's idea, the idea of creating an open access to different level of "help" would increase the talent pool of developpers for different needs, with each being able to climb the ladder of importance the better they get at doing what they do. Imagine 25-100 developpers working on different aspects of the whole. Who cares if 1 or 5 of them leave at that time.

This complaint seems to be reoccurring every so often. I know I for one share many of the same frustrations.

One solution, which may or may not help, is to establish some sort of tracking of actively maintained and dead modules. This way it would be very clear to potential contributors, as well as end users which modules are suffering from neglect, lack of resources, etc. Another benefit is that someone wanting to get started working with XOOPS modules has a quick reference to see which third party areas are in the most need of help.

I know I myself have had to make a few customizations to modules occasionally, and even to the core of Xoops. But with no real way to funnel those changes back, they simply sit on my server. If I knew module "foo" used to be maintained by "X", I could send my changes to "X" and either take over maintaining the module, assist with current development (if the current maintainer is so inclined), or prepare a new release under the same name instead of forking a module to a new name.

Basically, I think there needs to be some improvement in the tracking of active vs dead modules, and a way for those interested in helping out to claim dead modules as a new maintainer. Oh, and the new xoopsforge.com seems to be reddundant with dev.xoops.org and the use of WP, IMHO, makes it a jumbled mess. Now that I've aired my complaints, I'll back them up by saying I would be willing to jump in and help out wherever possible or needed.

I think this makes sense, but forgive me if it rambles a bit. Mr Arthur Guinness and myself had a long night last night, and I'm just clearing the cobwebs now

Quote:

knowledge is the main key to it, familiarity and experience are secondary in my opinion.

speaking in terms of myself here, i haven't created any modules from scratch, that's beyond my knowledge and capability at the moment, but though expermimenting and messing with different modules & the core I have learned quite a lot more than used to.http://www.php.net is a good resource andhttp://www.mysql.com. also search for tutorials etc & then practice what you read. it isn't easy and it's time consuming, but if you want to learn, there's no quick way.. practice and experiment will give you experience in itself, but not enough to actually go out and do it. there's still lots and lots that i don't know, and i wouldn't even class myself in the category of knowing php to a workable level, i'm still at the basic level, a lot is logic tho, i've found that in some ways the logic with php in some instances can be seen if you have knowledge of electronics (and, nand, or, nor gates etc) well it helped me anyway, but then i do have experience in electronics.

best advice is Join a team, and get involved with development. of course the team has to be willing to offer advice when you need some help with something or you get stuck and then explain what you did wrong so that you know next time. and you have to at least have some knowledge. but don't be afraid to ask questions.

most of my knowledge and experience was gained just from reading the XOOPS forums and experiementing with modules.. changing this and that and seeing the results.

there could be multiple ways of achieving the same goal, and they could all be the right way of doing it, just that you used a different method to get there.. there could also be a wrong way of doing something, and that kinda input from people is invaluable, if some1 says that's not the right way to do it.. i would ask the question of why is it wrong and what's the difference between the right way and the method i used??

i think this could be better suited to a different topic tho as it is slightly off topic from Lances original post..