As the CMS bridge developer, it's no secret that I spend a great deal of my SMF time outside the SMF project. I see a lot of other communities and projects, and what is making them successful. Of course, I can't help but draw a comparison back here to SMF. I'd like to see some of the types of successes from other projects here as well.
One major part in the success of many other projects is the facility of third party developments (3PDs). I see entire thriving businesses based solely on the creation of themes/templates of a single CMS, for example. This is something that we just don't have here at SMF -- we never have had it. We have some great themes in our themes site, and we have some very talented people who read this board for new paid work each day, but I just don't see the same kind of commercial development community I see elsewhere. Of course, with commercial development in a community, there is always a healthy segment of OS development as well.
Keep in mind that for now, this post is solely for the purpose of gathering some information. It doesn't necessarily mean that anything that is suggested is going to happen immediately, or ever. It is simply a matter of putting out some "feelers" to see where our current 3PD community is at, and what we can do to help it grow.
So, the simple question is: What can Simple Machines do to help make your SMF-based 3PD projects grow?
I cant believe no one else has had anything to say regarding 3PD's but after the way a thread worked out I figured I might post this to see what people say.Heres the general thing that got me,what came before it was just some ideas on the issue and yes before you say the post was also in the wrong thread.
Kindred:
QuoteWe support the baseline SMF here. Sometimes we can help with general questions on mods... but specific support for mods needs to come from the mod author.
physicshelp4u:
Quoteyes fine but no one helps there lol...
Kindred:
Quoteand we do not support that mod in here....
So basically said there was only the mods creator or specific forum like wwwsmfarcade.com or whatever can answer a problem with a mod. Straight away this says if its 3PD's sod off.
If he had replied 'sorry but this thread is in the wrong place and also you should check the specific forum as well' this would go a long way towards selling SMF for 3PD developement. To me it was a bit of a nasty arrogant reply and makes it look like SMF has no interest in 3PD other than basic mods.
I wonder how many SMF faults are fixed on other forums like Arcade ect and dont basically tell people trying to make an integration to bog off.
I have used this as an example and the thread is now irrelivant but the very thing your looking for your also nipping in the bud.If the mod or 3PD developer doesnt mind people fixing their software which im sure they dont you need to open up to more general SMF issues other than SMF only.
If somone fails installing a 3PD on SMF and succeeds on another platform like phpbb then its another person gone.If people cant find the help they need for specific software then they will use other software thats easier to get help for.SMF as a whole has good support but look further out at anything other than standard and your almost snookered before you begin.
No matter who writes it you need to help support it,If a mod author got 40 different issues a week how is he expected to answer and fix it all alone? Half could be theme problems , mods , settings and may not be their issue either but they get the headach of sorting them out.
See the point ? ;)
I tend to agree, but I disagree on another point as well.
On one hand, it is difficult to support a codebase one isn't familiar with. The benefits of doing so, in my view don't necessarily outweigh the risks of that particular scenario. Doing this can detract from the overall quality of support and lead to increased frustration. Conversely, greater support for modifications MAY tend to increase both the pool of potential mod authors and people that work with and support them.
Theres also the fact that, we simply don't have the manpower to do this at the moment. Who's problem is this? Well, it is my problem mostly. There are a good number helping with support, but very few might be considered for a team position. This is a complex issue as well. One might say "well, why not lower your standards" and others might think that theres more to it than pure skill and knowledge. Truth is, both might be right, but there are other things to consider aside from standards as well. It goes right back to quality vs. quantity. As this project grows, however, it is becoming more and more evident to me that we need a balance of both, that we need to take potential and work with it to mold it into something more. It is a delicate balance.
In the end, theres really no way to know what would come of it without doing it. I do not disagree with your opinions, simply giving some of my own. It is not due to closed-mindedness that support for third party things isn't a priority here, but a conglomeration of other things, such as establishing a solid base for such things of which 2.0 is much of the result. None of us doubt that expandibility is one of SMF's finest points.
So what do I think? I think with increased manpower behind support it may be possible, and it'd be something that others in this market just don't do. But in the situation right now, I don't think its entirely feasible RIGHT NOW, but rather, should be something that is changed gradually... a goal, rather.
Thats enough from the peanut gallery for now :)
Thank you, Nightbre. :)
The problem with smf team members providing support for 'mods' is that they are unlikely to have used most of the mods.
Statistically speaking ;)
But as a mod author I notice a large number of mod support questions asked often turn out to be 'general' smf issues
- Installing mods manually
- Installing mods on custom theme
- Languages with other mods
- Problems applying it (chmod permissions/server restrictions on webfetch).
those are questions that the team should be able to help with (In the mod support topic).
But for others issues, really the only people who may be in a position to assist is a) mod author, b) users who have installed the mod. (and unless the smf team members have used it, they are unlikely to be able to assist with these).
[I do appreciate the support already given by smf'ers for my mods, and I'm sure other mod authors feel the same]
QuoteTheres also the fact that, we simply don't have the manpower to do this at the moment. Who's problem is this? Well, it is my problem mostly. There are a good number helping with support, but very few might be considered for a team position.
Quote[I do appreciate the support already given by smf'ers for my mods, and I'm sure other mod authors feel the same]
This is one of the problems.You shouldnt assume that the SMF team or a mod author are the only people who will try to answer thats the point. The thread I used for example wasnt answered by the team until it was effectively servered in terms of the replies.Even if SMF were not prepared to look at the issue ,it and others similar could be answered more tactfull.
If a mod author doesnt mind others answering it can alleviate a lot of burden if they have a few mods released like Karl for instance.Im not saying everything could be fixed but some of the basic stuff that Karl listed would be found by others or resolved if its just how to install ect.
Open a New board entitled Unofficial 3DP support so If people are willing to try to fix problems they can.If I make a mess of SMF its reinstalled and ok again but its my choice to try.You cannot police people on how or what they reply to or what they try on their install, you just make it clear if it gets messed up its not SMF's doing.
I have some ideas for pretty big addons for SMF and im sure others have ideas as well.But if something like Arcade is developed for SMF at least show the courtesy of allowing SMF users to try and resolve issues.Hundreds of threads get answered and resolved by non SMF staff a week already so whats the difference.
Its not a case of adding burden to the staff more of one that SMF should open up a bit to things other than itself.I dont expect any team member to need to do anything particulary bar answer any posts if they feel like as normal but it will give outside SMF sources a focal point here and also people who want SMF as the core to add other things to it not particularly thought of here.It would work like any post,if you dont know the answer you maybe suggest where you can find it on another site ect.Staff shouldnt at all feel pressured into answering sice it would be a kind of voluntary board for support.
I know what you guys are saying over SMF 2.0 and issues directly with SMF but just be that little bit welcoming to outside things even if kept at a distance with posts to explain its purpose.I love SMF and am still learning a lot but people like me are the makers of tommorow and anything I make will be for SMF. It is amazing some of the sites you see then see SMF at the bottom and think wow because some of the features are uber.
Dont sell yourselves short guys SMF can go far. ;)
My only point which maybe I wasn't 100% clear.
My opinion is that EVEN if smf team members provide support for mods. It should STILL be done ONLY on smf.org via the Support Topic for that mod. Not creating other new topics.
It keeps all related posts together and related.
This is all good feedback, thanks guys.
I think I'm looking for something bigger than just boards and topics here on this forum/site, though.
Let me show an example from another project (Xoops):
http://www.xoops.org
I can, in just a few clicks, find a number of 3PD communities that develop Xoops-related products. These have nothing to do with the Xoops team at all -- they operate independently offering Xoops modules/themes/extensions:
http://www.marcellobrandao.eti.br/
http://www.bezos.cc/xoops/
http://www.e-xoopsfr.com/
http://www.chronolabs.org.au/articles/Xoops_Modules___Hacks/X_Soap_3_0_1/
http://xoopsforge.com/
And many more.
Keep in mind that these sites are all independently owned and operated by 3PDs.
How do we get SMF to that point?
@nightbre: I see what you're saying and agree, but we don't and never have said that the community can't help each other out with such things, either mods nor support.
Perhaps i'm not fully seeing the point you are putting across?
The point is likes of arcade and Tiny portal are 3PD's that have their own site on the internet but it should not make a difference if a problem is resolved here on SMF.Most of the replies say goto xxx site instead for support its not supported here.
QuoteI can, in just a few clicks, find a number of 3PD communities that develop Xoops-related products. These have nothing to do with the Xoops team at all -- they operate independently offering Xoops modules/themes/extensions:
Like I use eqdkp but their support forum is so poor it makes you cry.All the problems ive resolved with it have had the answers found on other sites bar its home one.So if i was to ask a question here and be told goto the official forums it would be easier to bang my head on a wall and hope the problem goes away.
QuoteSo, the simple question is: What can Simple Machines do to help make your SMF-based 3PD projects grow?
These 3PD's were not neccacarily developed here but people using SMF will still look here for help when the creators site isnt answering problems because they are still SMF based.Im Saying show that SMF supports these creations, I know not officially but it would give a good impression and maybe tempt more shall we say proficient programmers to extend SMF via 3PD's.
If I as a single individual write for instance SMF auction portal.I set up a support site to my module.But I then get hundreds of support questions and struggle to answer them.I may be tempted not to make updated versions if I cant cope or just abandon it as some mods seem to do.This then leaves anyone using the module stuck to find any way of fixing it unless they can work it out themselves or find alternative info on the net.
Thats where SMF could bridge the gap in terms of showing willingness to help but not neccasarily as the official help.Maybe agree with the designers to answer problems here if they dont object.From what I have read most mod makers welcome help from others and I dont expect Large project makers would mind some unofficial help for some of the easier solutions.Although these projects are large standalones they were still written with the intention of SMF being the crux of it all.Some of these may end up going commercial once they have beta tested and get the confidence up to do so.
nightbre... Your complaint seems odd to me...
the problem is: Support questions for 3rd party things, (mods, themes or other expansions) do not belong in the SMF 1.1.x or SMF 2.x suppoort area.
There IS a board (on simplemahcines.org) dedicated to supporting those 3rd party things. The mods board has a thread for each and every mod.
The themes board has a thread for eahc and every theme.
Questions about those mods or themes should be posted in those threads.
I provide support for a number of mods. Ones that I am familiar with... and ones in which I have marked the mod support thread as something to regularly check. You are also much more likely to have someone who has either encountered the same problem with the same mod, or is familiar with the mod when you post in the mod specific support thread.
So, it's not that I don't provide support for the 3rd party stuff... it's that the question should be asked in the appropriate area, not in general support, which is primarily for SMF base-code related questions/issues.
It is, as always, the author's repsonsibility to support anything that he writes. If SMF support staff or SMF members are familiar with the mod or can help debug it... then great (and many of us do so) but my point remains, support for 3rd party stuff does not belong in the general support area, since third party mods changes the baseline code, sometimes away from the simple answers (like the guy who has 103 mods installed...).
The other point is that people apparently don't like to read previous threads or use search... because 75% of the questions that are asked regarding mods have alreayd been answered in the support thread.
Kindred: i don't think its so much a complaint as it is feedback, to be fair.
both of you present some very good points. I do feel we need to be more open to third party development.
To be fair as well, some such mod authors ask that support inquiries go to their individual sites. We aren't just offloading it because we don't want to do it.
Quotenightbre... Your complaint seems odd to me...
You are the odd one sorry m8..., If you read the thread properly you would understand what its about and its just feedback to see how SMF can help 3PD's.
I cant be bothered to make much of a reply ive said all I think SMF needs to know,mods were used as an example.
I think Kindred has a definite point. You do as well.
Some of the 3PD are so big (like TinyPortal, Arcade, Shop, etc) that their developers have seen fit to create an entire support board for them. Registration is generally open on those forums, so those that feel comfortable with offering support for those mods can become a member on those forums as well.
I think your point about overwhelmed mod authors is valid. So, too, is Kindred's point about every mod having a dedicated support thread here on Simplemachines.org. There are many mods where the authors are infrequently active, and so support is mainly handled by experienced users of the mod, rather than the author.
Also, I think it's important that we continue to stay positive about comments in here. Everybody has a valid point and should be considered without simple dismissal.
right... I wasn't trying to say nightbre was "wrong"... I just don't understand the insistance that support for 3rd party mods should be handled in the general support area.
3rd party stuff needs support, no question about it. The primary support should be the 3rd part author. Secondary support should be users and/or staff who have experience with coding or with that specific mod. However, I believe that 3rd Party support does not belong in the general support... nor should it be the primary task of support staff to support the thousands of mods that are available.
We don't even do that (officially) for Charter members.
Quotethe problem is: Support questions for 3rd party things, (mods, themes or other expansions) do not belong in the SMF 1.1.x or SMF 2.x suppoort area.
I fully agree they shouldnt be posted in the support area and each mod does have its own thread for help in the mod section which is true.
Quoteand yes before you say the post was also in the wrong thread.
;)
I just used the mods as an example but what is meant if I can make it sound simple and right is this.
If a large modification like Tiny portal even though it has its own home site ,SMF should have some provision to allow for problem solving and feedback on it.Were not talking the mods threads here with 1 topic and 900 pages of fixes but a sub board if the modification maker wishes or allows.You could add a section to Customising SMF calles 3PD Modules then allow a child board inside for a qualifying Module.
All normal mods made by users will stay in their normal places.A topic for a module would only be opened at the request or with permission of the maker.This means that only those who agree to allow it will be allowed to use SMF 3PD forums to help with issues.
If somone looks up Tiny portal or Arcade for that they inevitably need to come here to SMF for the forum software to run these things.But the thing is they get to the site and are exposed to SMF even though they originally didnt even consider it!. They will be helped when they have install issues and config problems then get to a Tiny portal problem and we have the issue where they are told go look on Tiny portals site for support.
The issue here is like I say go try get support for EQdkp and you have more chance of proving E=mc2 is wrong.Not all people good at code are good at supporting large user bases and if your very small in terms of staff it can be impossible almost.Just one member of SMF team answer all the posts on here in a day and see. :P
SMF needs to extend the hand that says it does endorse the developement of Major modules and provide a small space where they can be discussed properly. All this stuff is written for this software made here on SMF and you need to look further out than just fixing the forum itself and mods to make developers feel that SMF is worth investing a lot of time into 3Pd developement.
It wouldnt and shouldnt fall down to SMF staff to actively fix issues but it would provide a kind of hub for developers alike as well to maybe see each others issues first hand and learn from it as well.If something is abandoned or has poor support in general it may help because SMF users are trying to integrate into the same kind of software rather than different answers mixed because users have different forum requirements.
The current mods show how people are willing to help if they can and are allowed to.I see it as finding a balance where 3PD's can be discussed here and maybe some issues resolved but not to the point where SMF staff feel they have some active role to play.
I know SMF is a biggie in itself to maintain. :)
alright then. :)
We're apparently on the same page.
Mind you... it's pretty much the mod authors that say "Please address support issues to my own site..."
So what criteria should be used for granting a mod a subforum? How does one determine what is "large enough" or whatever criteria is used?
Most of all, why should the SMF team be responsible for supporting a modification? Isn't it complicated enough to support the numerous features and settings, along with everything that can go wrong with them during normal usage, not to mention installation, upgrading, moving, and converting the default software? Now you want to add knowledge of these mods and dedicated support for them?
I wouldn't mind a place where current 3PD projects can link their sites on. Many of them have that in the form of records on the mod site. Others, like TinyPortal, don't have any current files in the mod site because the project isn't yet mature. But I think that's asking a bit much for mod authors to transfer their sites to the SMF official site and congregate there. For me, it seems like that's forcing the community into one place, instead of allowing them to expand outside of the official site.
How many resource sites are there for vBulletin? For Joomla? Those sites follow a similar philosophy, mods are listed in a repository, and then linked out to each mod author's site. Sometimes those sites are just threads on the official forum. Other times, they are actual websites those authors have made to give dedicated support for the mod. I don't see SMF needing anything more than this, not much more than it already does, at least.
QuoteMost of all, why should the SMF team be responsible for supporting a modification? Isn't it complicated enough to support the numerous features and settings, along with everything that can go wrong with them during normal usage, not to mention installation, upgrading, moving, and converting the default software? Now you want to add knowledge of these mods and dedicated support for them?
QuoteThe current mods show how people are willing to help if they can and are allowed to.I see it as finding a balance where 3PD's can be discussed here and maybe some issues resolved but not to the point where SMF staff feel they have some active role to play.
Allow discussion not move the whole site...
So just duplicating what's already there? We have mod support topics, and many of the 3PD authors have their own sites. Discussion could not freely exist on either of those two mediums?
I'm afraid I just don't see the point.
I think a forge would greatly help 3PDs. Ideally, if SMF were to take a more simple FOSS licence, and the mods on the mod site were required to have one too, and if we had a forge, then having community support would be much easier. No longer would we be required to wait for mod authors to fix stuff, submit a patch, and have either the customise team rebuild the packages, or even let trusted community members do it too. At the moment there is little advantage for using sm.org's customisation site other than publicity.
QuoteSo just duplicating what's already there?
Its not in the same sense as a normal mod.The thread for a single mod is sufficient but if a 3PD was present then a single thread would become extremely cluttered with old fixes for versions gone by like some of the mod threads now.Any mod thread I look at I read the last page first as I know the first 30 -40 are all old out of date fixes normally for older versions of SMF.
Also with a large 3PD the problems may span various different aspects of its design and code and a single thread would end up confusing.You have to look at it from a laymans terms and things you know and expect they may not.This site as it is can be murder if you have no idea of SMF and confusing if trying to find a thread buried 40 pages down because the author cannot or doesnt answer problems with his mod.
The idea is to make a sub heading say for a portal that incorperates 100 features. Then there can be a couple of threads inside for Install, Troubleshooting , Upgrading ect. Obviously the maker must agree but I doubt most would turn down the option to integrate some discussion here on SMF since the feedback could be valuable if they wanted to make a commercial version eventually.
So, I'm going to summarize what's here so far:
- Better methods of supporting third party software on-site
- A 3PD forge
- OSI approved license
- Child boards for qualifying mods (determine definition for "qualifying")
Great stuff. :)
What else?
Quote(determine definition for "qualifying")
To me something similar to this line.
A modification or major addition that doesnt simply manipulate the existing forum code but adds significant 3PD code and php files/scrips/sources of its own to operate effectively.
The definition would need carefull consideration but something along that line as a starting point maybe.
Quote- Child boards for qualifying mods (determine definition for "qualifying")
This wouldn't necessarily be needed. There are other options. For example with a tagging system the topics could be anywhere (though hopefully just in a general mod support area) and then tracked by the forge. Then any mod can have more than one topic, not just the qualifying ones. The forge could even have something like the support topics page, and show a mod author any tagged topics they haven't replied to yet.
- Mod Contest
- Mods of the month (most other forum software seem to do it, why not smf). Awards = recognition.
- Easier Transference of mods (some great new mods start, then fizzle out as the author loses interest of is a one man band)
- Sharing mods - multiple people allowed to edit/update/contribute to a mods. Mod teams (Competition is a wonderful thing)
Quote- Easier Transference of mods (some great new mods start, then fizzle out as the author loses interest of is a one man band)
I think that can be accomplished with licensing and the forge as previously mentioned.
Quote- Sharing mods - multiple people allowed to edit/update/contribute to a mods. Mod teams (Competition is a wonderful thing)
That can definitely be accomplished with a forge.
Excellent stuff. Keep them coming!
I just had a thought on this. A 3PD forge would make this easy to grab the most up-to-date packages of the mods, and do what many linux distributions are doing with their software: a make-your-own package. This could make installation of these large 3PDs much easier, to have them pre-packaged with SMF in a build-your-own style.
Think of selecting the latest build of SMF and being able to download it preinstalled with TP 0.9.8 or SMF Arcade? Would make mods even more consumer friendly.
Quote from: Eliana Tamerin on May 17, 2008, 01:10:19 AM
I just had a thought on this. A 3PD forge would make this easy to grab the most up-to-date packages of the mods, and do what many linux distributions are doing with their software: a make-your-own package. This could make installation of these large 3PDs much easier, to have them pre-packaged with SMF in a build-your-own style.
Think of selecting the latest build of SMF and being able to download it preinstalled with TP 0.9.8 or SMF Arcade? Would make mods even more consumer friendly.
The SMF license forbids that. Do a search for SuperMod if you wish to find out why that will never happen.
No problem, then. I'll just sit back and keep watching here.
Here's a bid idea, you have svn set up, so how about offering it to mod and theme authors? Or you could set it up on another server seeing as you've got the skills to do that.
Quote from: Eliana Tamerin on May 17, 2008, 01:33:33 AM
No problem, then. I'll just sit back and keep watching here.
Sorry, Eliana, I didn't mean to diminish your contributions to the topic. That particular suggestion, though, strikes at one of the main reasons why the SMF license was created in the first place.
QuoteHere's a bid idea, you have svn set up, so how about offering it to mod and theme authors? Or you could set it up on another server seeing as you've got the skills to do that.
If we go the forge route, I believe that most forge software suites come with both cvs and svn utilities.
SVN is totally out imho, its should be used as an active development tool, not a showcase one. I reckon most mod auhtors do not want to risk being at the mercy of a central site going down, at least i am very opposed to that idea. At times when SMF site has been down, the Tinyortal site and others, has served as small news beacons during that, not hindering the slighest the development cycles and support there.
But getting big as some 3PD sites for Joomla for example is quite possible I guess, all it takes is people willing to take the plunge. How to make that easier I cannot say really, using the "supermod" way is def. out, as it presents as many problems as solutions, if not more :P
I guess its also down to popularity and getting more serious third-party developers on board - there I think SMF still appeals more to the beginner/home crowd than the business crowd. Of course SMF is well beyond mature enough lol, its just that we have a target audience that we serve very well - but its not the same as for example Joomla serves. PhpBB has the edge of being more known and longer in existance, same for the paid ones - which in themselves lend quite a bit of credibility just in the fact they cost money :P
We have the advantage of being free, have a powerful template system and a plug-it-in system for mods. Thats our main assets but again advancing 3PD needs something more I guess...Recent talks elsewhere about themes for example, being possibly in violation of SMF copyright, DOES not encourage others to bet on SMF. There we need to clarify and not speculate, NOT feeding the rumour that *everything* is in violation of copyright. :P Just the fact that mods/themes on 3p sites thrive already should be enough.
QuoteSVN is totally out imho, its should be used as an active development tool, not a showcase one.
I could possibly be wrong, Bloc, but I think that was the point -- an active development environment rather than just a showcase.
All points well taken. Your TinyPortal is actually the best example of a project that has flourished, and is a great example of SMF 3PD success.
Quote from: Orstio on May 17, 2008, 08:26:41 AM
Quote from: Eliana Tamerin on May 17, 2008, 01:33:33 AM
No problem, then. I'll just sit back and keep watching here.
Sorry, Eliana, I didn't mean to diminish your contributions to the topic. That particular suggestion, though, strikes at one of the main reasons why the SMF license was created in the first place.
No issue on my end, you're not diminishing my contributions. I'll keep posting ideas if I get them.
Besides, this was a good way for me to learn my history about SMF/YABB SE (and, YABB SM, I guess). You are certainly in the right to restrict that direction of development. I'd hate to see SMF form a version similar to PHPBB's Fully Modded package with loads upon loads of unneeded bloat and security issues galore. The reasonings are completely understandable.
If we wanted to start a forge (or perhaps a really rich community member wanted to?), we might be able to check with CollabNet about CollabNet EE for running it. It's a nice system and used by a lot of other sites (Sun's Java.net site uses it, tigris.org - home of Subversion - uses it, etc).
As long as you don't use SourceForge's forge...
Drupal has a nice one, I don't know if it's available though.
Quote from: Dannii on May 18, 2008, 10:57:11 PM
As long as you don't use SourceForge's forge...
Funny enough, CollabNet bought SFEE from VA Software (Now Sourceforge, Inc). They are selling it alongside their solution, CollabNet Enterprise Edition. Having seen the code of the SF platform (via gForge), I would stay away. It requires unsafe PHP practices and the like.
Only downfall to CollabNet EE is that you need to configure JSP and the like. It operates wonderfully, however. If my personal dev server was a bit more powerful (it's a dual 500mHz P3), I'd probably run the free 5-user edition.
Quote from: Dannii on May 18, 2008, 10:57:11 PM
Drupal has a nice one, I don't know if it's available though.
I think it might be in the Drupal-Forge (http://savannah.nongnu.org/projects/drupal-forge) project at Savannah? It looks like it needs Drupal as a platform, not surprisingly.
However, we should go back on topic.
At the risk of being called idiot -
Does 3PD's also include site selling Paid Mods/Themes?
Quote from: Dragooon on May 18, 2008, 11:50:53 PM
Does 3PD's also include site selling Paid Mods/Themes?
Yes.
Thanks :)
If trac was easy to install for multiple projects it would be the best option IMO. Everyone seems to be using trac these days.
Commercial mods and themes in the scope of 3PD, but do we want to be encouraging them on sm.org? I wouldn't think so. People will develop commercial customisations regardless of what changes we do.
Well, if SM.org doesn't wants to promote them I guess thats fine.
I must have missed something lol..how can we promote commercial projects, if we setup a sourceforge? Surely most serious players would want their own site/place anyway? Only reason for it afaik is that we can have commercial mods/themes next to free ones, but other than I fail to see how it will benefit anyone. We would just move the mod/theme site to another place.
I thought the idea was to have a site that took care of stuff that now reside on "help wanted" board..?
QuoteCommercial mods and themes in the scope of 3PD, but do we want to be encouraging them on sm.org? I wouldn't think so. People will develop commercial customisations regardless of what changes we do.
That's what I highlighted in my first post. We have a huge lack of both commercial and free mod and theme authors in comparison to other similarly sized projects. What I want to know is why, and what can we do to change that?
QuoteI must have missed something lol..how can we promote commercial projects, if we setup a sourceforge? Surely most serious players would want their own site/place anyway? Only reason for it afaik is that we can have commercial mods/themes next to free ones, but other than I fail to see how it will benefit anyone. We would just move the mod/theme site to another place.
I don't think anyone is talking about moving the mod/theme site. It is still an important resource.
Something you will notice about other projects is that there is really no division between commercial and free 3PDs. Most commercial 3PDs of other projects have a few free projects to showcase their abilities and then a few commercial projects for more feature-filled extensive capabilities.
QuoteI thought the idea was to have a site that took care of stuff that now reside on "help wanted" board..?
Completely different topic. :P
ok lol, my misunderstanding then. :)
How about an SMForge
SMF is forum software. Forum software implies that SMF is a component to be added to some larger thing. However, SMF's code is kinda geared to run the other way around. This has some far reaching implications that I suspect have not been fully explored.
The subject has come up, of course. We have Tinyportal (Cheers Bloc et al) and we have various bridges(while working on SMF-J1.5, the topic of SMF controlling the integration came up)
What I'm saying is that many of the modifications change the way that SMF operates. It's a psychological thing. "You should be able to use whatever functionality it adds, or not use whatever functionality it removes"..........
Why are we only addigng and removing functionality to/from SMF itself??
Some mods will change the XML feeds. SOme will change SSI....
Consider though, SMF is a community site. Now, how can your community exert a stronger influence on other communities?
What you want to be able to do is call SMF's procedures and suchlike from elsewhere.
Last FM has their Quilt of recently played music.
SMF can tell you how many unread whatsits you have, when you're out.
I'm working at this moment on some very large and complex SSI stuff. The ties to the forum will be hidden. The mods will draw information through XML-RPC from a third party site, process it, and display it on another 3rd party site with Javascript and/or iframes. CSS, SOAP, and all kinds of weird things will be going on.
I know, it's ambitious, like tinyportal ambitious, and will mayeb never be finished because it's insane.
But the point is that this stuff is using SMF to process something from A and paste it onto B.
The control panels for the stuff are only accessible through SMF. This way, when something breaks, my users can start a forumtopic or send a PM and let me know. I can utilize SMF's powerful permissiosn system. I acn receive forumPMs when assertions fail....
SMF offers a powerful, powerful framework that can create and administer applciatiosn that operate outside of the forum.
So, all I'm saying, in a roundabout way, is that there is a culture of only thinkign of adding features to a forum. Which need not be the case. I would like to see more focus on extending the forum outside of its comfort zone. It is probably just me, I can be prettycrazy ;) but perhaps if some minds can be blown, then it might raise interest in SMFmodification development from new and unexpected sources.
Yes, sorry, nothing to do with making mod devlopment or use easier,only suggesting something cultural.
Sorry for any typographical errors, sadly the theme here specifies that form inputs and textareas should have color: #000000; and they negect to set a background colour.
Black on black.. I's not very nice. I can't see what I'm saying.
Quote from: SneakyWho_am_i on May 24, 2008, 08:03:03 PM
Black on black.. I's not very nice. I can't see what I'm saying.
Click in the box and use CTRL+A it will highlight the text giving you a temporary white background.
Quote from: SneakyWho_am_i on May 24, 2008, 08:03:03 PM
SMF is forum software. Forum software implies that SMF is a component to be added to some larger thing. However, SMF's code is kinda geared to run the other way around. This has some far reaching implications that I suspect have not been fully explored.
The subject has come up, of course. We have Tinyportal (Cheers Bloc et al) and we have various bridges(while working on SMF-J1.5, the topic of SMF controlling the integration came up)
What I'm saying is that many of the modifications change the way that SMF operates. It's a psychological thing. "You should be able to use whatever functionality it adds, or not use whatever functionality it removes"..........
Why are we only addigng and removing functionality to/from SMF itself??
Some mods will change the XML feeds. SOme will change SSI....
Consider though, SMF is a community site. Now, how can your community exert a stronger influence on other communities?
What you want to be able to do is call SMF's procedures and suchlike from elsewhere.
Exactly.
Ditto.
The biggest problem precluding a strong 3pd community is SMF itself. Both as a software platform and an organization.
It closed (and close minded) very vertically integrated (heirachical caste system) and does not react or work well with "outsiders"
Because of the 'initial relationship/problems' with Yabsee (sic) there is a preoccupation and obsession with 'code being stolen'. Consequently, EVERYONE who works with SMF and develops with it is a potential thief until proven otherwise.
There is a small market parochial/clique mindset which is somewhat understandable because SMF is not 'open source'.
The foundation of any 3pd movement is evolution.
People evolve as 3pd's by (lets say) writing a few tips and tricks, then writing a mod (which earns critical acclaim) then leveraging that fame to develop a site then major projects.
Here, the barriers to entry are steep, and the behaviors of the 'gatekeepers' obtuse.
There is no 'transparency' or even accountability to the mod approval process.
There should be, initially and publicly, a display of mods recently submitted, what the mod is about, its position in the queue and why - leading up to its final "approval".
This allows new developers (budding or prospective) to see first hand the path and travails of a mod as it makes its journey.
Now, its a 'closed door visit to the Wizard of Oz behind the green curtain!'.
Mods languish waiting for 'approval'
SMF onerous /bizarre and arcane licensing.
Do you know that a plain reading of SMF license puts Theme authors in non-compliance?
Quote from: SneakyWho_am_i on May 24, 2008, 08:03:03 PM
Black on black.. I's not very nice. I can't see what I'm saying.
Once you go "black on black" you never go back!
Quote from: Orstio on May 17, 2008, 01:17:51 AM
Quote from: Eliana Tamerin on May 17, 2008, 01:10:19 AM
I just had a thought on this. A 3PD forge would make this easy to grab the most up-to-date packages of the mods, and do what many linux distributions are doing with their software: a make-your-own package. This could make installation of these large 3PDs much easier, to have them pre-packaged with SMF in a build-your-own style.
Think of selecting the latest build of SMF and being able to download it preinstalled with TP 0.9.8 or SMF Arcade? Would make mods even more consumer friendly.
The SMF license forbids that. Do a search for SuperMod if you wish to find out why that will never happen.
^ lol :( ..like a jilted or cheated on lover, still clinging to the anguish of her pain after all these years.
A more API centric approach, beefier more robust SSI routines, allow us to ADD SMF to our code/project, vs the other way around?
Make it easier to 'wrap' smf? ie. a SSI call vs tons of bloody layers research?
a mod add on system more like Mambo's where mods are included at run time vs clunked into the code.
This will allow you to separate code from the core/clean SMF - the inclusion doesnt have to be via a database lookup like Mambo, it could like a config file that is written/rewritten as mods are added removed.
(the old way of directly inserting lines of code may still be needed/necessary but here's hoping it can be deprecated a lot)
SUMMARY:
Attitudes.
Transparency
API
Better code base
Some interesting thoughts to ponder, Steighan. I really appreciate your perspective.
Could you explain what you mean by a better code base? I think I caught your explanations for attitudes, transparency and API, but not sure on the code base. Is that the mods issue you were talking about?
One thing I will chuck in here briefly is that we are constantly striving to make SMF more modular and API like. Comparing 2.0 to 1.1 and then to 1.0 you'll see we've tried to abstract as much functionality as possible to make it easy for people to integrate (Either through SSI or using direct includes). One thing we'll be looking at in the future (After 2.0) is to make SMF even more modular/API like to try and reduce the overhead. The one problem with SSI is that it unsurprisingly includes a lot of overhead that isn't *always* needed. I'd like to see us move to a system where things are much more modular so a developer/site owner can decide which bits they want and don't want to use on a case by case basis.
I'd have to agree with that, also in the interface portion, SMF is far more modular in 2.0 than 1.1. The features and options area can turn portions of the code on and off, and if turned off, those administration areas don't even appear. Useful for admins who don't want to bother with the karma section, or don't need custom profile fields.
Quote from: steighan on June 01, 2008, 12:25:04 PM
Quote from: SneakyWho_am_i on May 24, 2008, 08:03:03 PM
SMF is forum software. Forum software implies that SMF is a component to be added to some larger thing. However, SMF's code is kinda geared to run the other way around. This has some far reaching implications that I suspect have not been fully explored.
The subject has come up, of course. We have Tinyportal (Cheers Bloc et al) and we have various bridges(while working on SMF-J1.5, the topic of SMF controlling the integration came up)
What I'm saying is that many of the modifications change the way that SMF operates. It's a psychological thing. "You should be able to use whatever functionality it adds, or not use whatever functionality it removes"..........
Why are we only addigng and removing functionality to/from SMF itself??
Some mods will change the XML feeds. SOme will change SSI....
Consider though, SMF is a community site. Now, how can your community exert a stronger influence on other communities?
What you want to be able to do is call SMF's procedures and suchlike from elsewhere.
Exactly.
Ditto.
The biggest problem precluding a strong 3pd community is SMF itself. Both as a software platform and an organization.
It closed (and close minded) very vertically integrated (heirachical caste system) and does not react or work well with "outsiders"
Because of the 'initial relationship/problems' with Yabsee (sic) there is a preoccupation and obsession with 'code being stolen'. Consequently, EVERYONE who works with SMF and develops with it is a potential thief until proven otherwise.
There is a small market parochial/clique mindset which is somewhat understandable because SMF is not 'open source'.
The foundation of any 3pd movement is evolution.
People evolve as 3pd's by (lets say) writing a few tips and tricks, then writing a mod (which earns critical acclaim) then leveraging that fame to develop a site then major projects.
Here, the barriers to entry are steep, and the behaviors of the 'gatekeepers' obtuse.
There is no 'transparency' or even accountability to the mod approval process.
There should be, initially and publicly, a display of mods recently submitted, what the mod is about, its position in the queue and why - leading up to its final "approval".
This allows new developers (budding or prospective) to see first hand the path and travails of a mod as it makes its journey.
Now, its a 'closed door visit to the Wizard of Oz behind the green curtain!'.
Mods languish waiting for 'approval'
SMF onerous /bizarre and arcane licensing.
Do you know that a plain reading of SMF license puts Theme authors in non-compliance?
Quote from: SneakyWho_am_i on May 24, 2008, 08:03:03 PM
Black on black.. I's not very nice. I can't see what I'm saying.
Once you go "black on black" you never go back!
Quote from: Orstio on May 17, 2008, 01:17:51 AM
Quote from: Eliana Tamerin on May 17, 2008, 01:10:19 AM
I just had a thought on this. A 3PD forge would make this easy to grab the most up-to-date packages of the mods, and do what many linux distributions are doing with their software: a make-your-own package. This could make installation of these large 3PDs much easier, to have them pre-packaged with SMF in a build-your-own style.
Think of selecting the latest build of SMF and being able to download it preinstalled with TP 0.9.8 or SMF Arcade? Would make mods even more consumer friendly.
The SMF license forbids that. Do a search for SuperMod if you wish to find out why that will never happen.
^ lol :( ..like a jilted or cheated on lover, still clinging to the anguish of her pain after all these years.
A more API centric approach, beefier more robust SSI routines, allow us to ADD SMF to our code/project, vs the other way around?
Make it easier to 'wrap' smf? ie. a SSI call vs tons of bloody layers research?
a mod add on system more like Mambo's where mods are included at run time vs clunked into the code.
This will allow you to separate code from the core/clean SMF - the inclusion doesnt have to be via a database lookup like Mambo, it could like a config file that is written/rewritten as mods are added removed.
(the old way of directly inserting lines of code may still be needed/necessary but here's hoping it can be deprecated a lot)
SUMMARY:
Attitudes.
Transparency
API
Better code base
The main problem with your statements is the assumption that forum software is/will be a component to something other. Its not, and it really is fruitless to expect it to be. Yes, many things have been done to SMF 2 towards it being modular, but its NOT intended for SMF to be the next plugin for the CMS-flavour of the week. "Bridges" is the key here, that will allow software to work together - not having to consider impact on other software when we strive the make SMF the best FORUM software out there.
Maybe we should just chuck out everything not needed in SMF and convert SMF to a Joomla component? Saves us lot of work and easier in the long run too. Most people want Joomla anyway, we would just be doing them a favour. :P
I thought that's what Joomlaboard was. :P
QuoteThe main problem with your statements is the assumption that forum software is/will be a component to something other. Its not, and it really is fruitless to expect it to be. Yes, many things have been done to SMF 2 towards it being modular, but its NOT intended for SMF to be the next plugin for the CMS-flavour of the week. "Bridges" is the key here, that will allow software to work together - not having to consider impact on other software when we strive the make SMF the best FORUM software out there.
Maybe we should just chuck out everything not needed in SMF and convert SMF to a Joomla component? Saves us lot of work and easier in the long run too. Most people want Joomla anyway, we would just be doing them a favour.
I don't think that's what Steighan is getting at.
Think of adding a menu button to SMF. Immediately you are thinking of modifying the code in your theme.
Think of adding a custom action, and you immediately think of modifying the array in index.php.
Think of adding a Skype button in the user post display info, and you are thinking of modifying at least two source files and two template files.
I think what Steighan is getting at is the fact that in the CMS world, they would never begin to think of making their 3PDs modify source code to accomplish such common things that mods do. They should be set up in such a way that code modification is not required to accomplish them. It's understood that not all mods can be treated this way, but common things like adding buttons, or adding custom actions that change nothing else should be modularized eventually.
Hm, if so he described it poorly. These are features already in or planned for SMF2 so we are on that path already.
And excuse me, but why are you comparing SMF with CMS systems? Is SMF a CMS or a Forum software? I agreed that modularity is important and that mods should much more be "plugins" rather than actual source code modifcations..but is that really important when SMF is not meant to house big unforeseen extensions like a CMS by nature does/should do?
exactly, Orstio.... now, I'm not against code being modified per se, i.e. at rountime, not having to do a database query to assemble all the different components (and build their parameters) is a much needed optimization especially in high demand/shared hosting environments.
But:
I need a new functionality to my forum site. I "add a button" no?
Ideally, I would like activities under that button to show up in the "Who's Online" list and be shown up as part of the site.
Currently I have to hand modify so much code my head explodes -AND this hand modification is in peril when I update.
Lets say we forget about
APIfying SMF in the manner of a CakePHP or some other (one of the many) code libraries.
Lets say that SMF is Forum, 1st, foremost and only.
It should still be much easier to add code to run within the context of SMF without the current machinations that have to take place now.
Many mod problems are to do with installation, and the tight coupling of "Theme" (appearance) and basic functionality (function) is disturbing.
It brings to mind the American system of "separation of church and state" maybe you DONT want the Pope (or the Ayotollah) in the White House.
With all this tho, SMF is still hands down (up?) right up there as one of the best, and is best in many categories for me over even VB or IPB. That it is not more 'out there' right now given its obvious quality is surprising at first.
Making it easier for people to use and distribute:... not so much an issue. The argument mentioned earlier about "How cool it would be to get a copy of SMF already installed with SMF Arcade..."
If the modules and extensions were less intimately entwined with the code, then this wouldnt be so much of an issue.
SUMMARY:
---------------
Best way to grow 3pds
1. Start with SEEDINGS: - make it easier to code extensions
the "Api/function library" has NO working examples whatsover. :( also, the usage/behaviour of some of these functions are not obvious-there are caveats/pitfalls that only become apparent after a while then you go "oh!"
2. Make it easier and more transparent for this growth to be seen.
3. Feedback/Rating system for mods, kinda like ebay(tm) (Recognition)
That is the "grass roots level"
at the higher level, for people whom are already established developers and would like to enter the SMF "market"
1) Show them it can be worth their while.
Business demands transparency and predictability more than 'fairness'. Since business is all about risk, making whatever risks clear and upfront is important.
Limit license risks - make it legal for people to release a custom distribution of SMF as long as their distribution site indemnifies SMF, links to the SMF 'virgin copy' download site and that they pledge to update their modified version within 14 days (or whenever) after SMF updates itself.
Feature a 3pd every 2 weeks and what they do.
It would be a good public service as many people dont even know of whats out there.
Right now, there is a generic "wanted board" which either allows exploitation or shoddy work. (There are success stories too, but does anyone get to see?)
At least making success more visible would be a good thing for both the merchants and the marketplace
Have a 'code of ethics'' that promotes a level playing field and ensures that diligent hard working 3pds arent undercut or tarred by the fly by night ones.
For the community:
Some improvement is already visible here: You can now see in the themes section "Themes for your version of SMF" this saves a lot of time finding out exactly what is available.
@Block
Quote
And excuse me, but why are you comparing SMF with CMS systems? Is SMF a CMS or a Forum software? I agreed that modularity is important and that mods should much more be "plugins" rather than actual source code modifcations..but is that really important when SMF is not meant to house big unforeseen extensions like a CMS by nature does/should do?
Your own TinyPortal is indicative of the fact that, when people have built a community (Forum) then they need to start catering to that community.
Since not everything they need cannot be summed up as (or dismissed) as a topic, post, or thread, then something ELSE is needed.
You have 5000 members, you need more than a "sticky" you need a 'frontpage with the hilighted news item"
SMF has a "news fader", but it is woeful - its not even in a database, and again, thats where YOU fill that niche.
Obviously, if SMF evolves properly, TP and its ilk will become redundant. I can sense your disconnect there, but "but is that really important when SMF is not meant to house big unforeseen extensions like a CMS by nature does/should do?"
yes it is.
The lines are blurring all the time, while SMF should "do what it does best", "dont forget who brung you to the dance" and so on, making an arbitrary line in the sand as you describe and fearing to cross it does no good.
(gets on a MLK/Obama soapbox)
I have a dream, when CMS and Forum shall join hands (or at least, PHP code) to provide the best in community and text management, when a site is known, not just by the color of its skin (i.e. Template) but by the robustness of its forums.
When news items in SMF newsfader are not little one line blurbs, but actual NEWS that may be pulled from the calendar or from a news post, a dream where, I could assemble a complete SMF forum from a Flash .swf or even a .NET control and none would be the wiser, save for my link to http://simplemachines.org
Yup, quite right TP is in fact the same thing I am objecting against here lol :) - but it is and always will be a modification for SMF, a sidetrack of the forum as so many other mods. You see, I don't WANT the forum to be anything other, because it excels at it. Lets put it this way: if SMF hadn't been so secure and fast, TP would made it significatly slower, simply because its code (TP) is putting more strain on it.
The 3PD's can feed off that great base code and add, sometimes, much slower code without everything going downhill. I have tried a few of so-called CRM systems and its a relief that SMF has stuck to its goals lol.
I am not really sure what your overall point is, but its clear to me that by not becoming a CMS copy, but rather go its own path as a forum software with useful and meaningful extensions/features IS the best way. There are awful lot of things in a CMS that are "nice"..but oh so irrelevant for what SMF primary is meant for.
yeah, but think how much better TP would/could as an EXTENSION if some better facilities were part of the CORE?? That way, you would have been able to concentrate your coding efforts on the user interface and implementation of features, vs core functionality?
for instance, the "sc" construct that allows you to store the current session in the form to prevent CSRF.. or the SQL Safe string filtering routines? Thats basic form security code that SMF has had from way back when, and Joomla only just implemented after some arm twisting by Phil Taylor.
That kind of functionality didnt have to be exposed the way it was for SMF to incorporate it, but it was, and anyone coding in SMF context is encouraged to use such library functions to make their code more secure.
'Nother example...the SMF buddy list... what if it were even slightly abstracted to allow the buddy list to have an "owner" or designated "master" (which it does in a way - YOU are the master of the buddy list :P) but a bit more tweaks to that concept could allow people to create their own self moderated groups WITHIN the board , a clique if you will.
Community builder allows people to make associations like that, but then cant do anything other than maybe PM each other when they are associated!
But SMF already has the 'discussion forum' aspect built in, so , once they have associated themselves into their little clique, they can collaborate in their own little board within a forum (semi private- the Admin is after all, God, and sees all) but private enough.
Looked at in a slightly different way, the "buddy list" with its explicitly (as opposed to the current implicit) defined master or parent, could form the basis of an AOL like registration scheme, where there is one master account - the bill payer and the associated, but independent child accounts.
the level of 'independence' can vary of course but that can all be defined at the implementation level by the mod designer creator - the base structure is there!
Fully fleshed out with all the 'tools' such a structure requires, i.e. List Children (accounts) of Parent account... list Team members of (team) etc etc.
Again, I would say that we shouldnt say what SMF is 'meant for'
lets instead say, we will recognize and continue to build SMF "core strengths" but dont let us self censor or self limit ourselves :D
/blather
Just though I'd post on the idea of mod subforums again. I now think they're not required. I have the 5th largest topic (probably soon to be 4th) and I haven't had any trouble keeping up with supporting my mod in a single topic. If there are mods that are generating an unmanageable number of support requests it's probably because the mod is very badly written. I think it would be better to provide further mod docs and possibly raise the mod coding standards.
I think modifications that are in request by many people that have been "discontinued" by the author or the author hasn't kept up with the latest releases should (at least tried) to be taken over by the SMF Development Team. For people, like myself, who have no knowledge (or only enough to edit variables and insert comments :D ) of php find it very difficult to get exactly what they want out of SMF. If the mod(s) they're looking for are outdated or aren't available, of course they'll turn to another option even if SMF does have some really nice core features.
it is not the smf team's responsibility to pick up dropped 3rd party development... nor do we have the time to do so with our focus being on development of the SMF core.
Also if you make a post in mod requests regarding the particular mod your looking at somone may be willing to try and update it or already have a fix they have come up with.
The SMF is busy on SMF core development but some of the mod makers anyway may be interested in looking at some mod worth maybe updating if its brought to their attention.
If you see an outdated mod, contact the developer and ask them to update it. If they don't have time to maintain it, they can also post on the forum asking to have someone take over development. That way everyone wins - the community can enjoy the mod, and the mod author doesn't have to worry about not having time to maintain it.
Hmm... what about adding another staff member (or group, like the Beta Testers) to update mods from people who haven't been online for over a year and can't be contacted? I'm sure there's a few of us here who would gladly just update mods for the latest release of it's line (1.1.4 -> 1.1.7, 1.0.8 -> 1.0.15, etc.) and provide minimal support for orphans :) and if the original author comes back, they still retain ownership and can continue development if they wish to.
Just an idea!
The problem comes from determining what license they used and if that gives permission to actually do that.
That would be a little tricky, yes... what about adding a checkbox on the mod edit page that says something to the effect of "If I cannot be contacted for 30 days, permission is given to (Simple Machines/whomever) to update this modification for security and compatibility reasons." in bold so that it's noticed?
And of course leave it unchecked for all old mods, and auto-check it for all new mods... would that work?
QuoteThe problem comes from determining what license they used and if that gives permission to actually do that.
Make a condition that mods must be open licence so if they are abandoned then somone can continue developement of them.OR just split mods into group categories.Dont actually split the mod site but give the mods a rank label with its status as licenced,open,active or abandoned if not upgraded for 3 months after an upgrade is required.
This would give an indication of how active a mod is as well as flag it for upgrade after a pre determined time.Maybe a timer on mod site so when SMF is changed it is reset and counts down for 3 months automatic.If the mod is fixed then it is cancelled.If not it will flag after the time as abandoned.When upgrades are not needed the timer is stopped again until one is.
A condition of submittal would be you agree if you let your mod become abandoned SMF can designate a new modder from who may be interested.
I think that having the team take ownership of any mods or themes defeats the purpose of trying to grow third party development.
If the team takes it over, it stops being third party. This is the opposite of growing third party development.
That's why it wouldn't really be "taking over", just babysitting it until the original author returns.
Let's say that I'm the one who leaves, and Orstio is a person who can update orphaned mods. If a security issue is found with the Referrals mod, he can make the applicable changes in the code and re-submit it as a bugfix. When I come back four months later, the mod is still in my name and I can continue where I left off, including the new updates from Orstio. Nowhere would Orstio's name be mentioned, except perhaps to myself on the mod page ("This modification was updated on March 17th, 2009 by Orstio. Reason: A hole was found in Referrals.php that allowed spammers to harvest email addresses.")
I personally feel that the team itself really needs to focus its primary efforts on the main core distribution of SMF and on the community here, specifically. I can see where it makes sense to do but we really do not have the manpower to also take on and learn mods, their inner workings, and the like. Even on enough of a basis of updating them. It isn't an unsound idea but I do not feel that it is workable to have the team take on that additional huge burden. Not to mention, that it might not even be LEGAL in some cases to grant someone else the right to do so without permission of the author
Moving onto the other discussion, the problem with explicitly requiring an open license is that it ALSO restricts what sort of mods can be found on the modsite. Some people, while they do release their code for free to the community for use, may desire to have their own terms -- which is understandable. It is, after all, their hard work. The main importance is that SMF retains the right to distribute the mod -- we are essentially giving them resources to host their works.
I can see an option on the modsite which allows for the author to "release" their mods to the community or release their mods for others to take over without need for a lengthy intervention between them and the customization team. I think that would help with orphaned mods the most.
Its a tricky situation... but I don't think theres anywhere we can intervene either legally or without doing more harm than good to third party relations by policy changes in being more uptight about what we accept. We can't legally take someone's work away from them. Especially in the US where copyright is assumed automatically. Forcing them to give up that right is also illegal in some cases, so i can see where that'd be a bad idea.
I'm not saying the ideas are by any means bad... but I don't think they're workable in this case. We cannot just give people the right to edit a work, nor can we force people to give that right.
Checkboxes aren't mandatory! Heck, you can even leave it unchecked by default if you'd like. Either way, there would/should probably be enough text nearby to give them a complete understanding of what they're doing by checking the box.
And I don't think it would ever take away from development of the core of SMF - people (like myself) who would probably never join the team but are capable of mod development could easily update orphaned mods every once in a while.
I think trying something like this is a lot more feasible than having mod authors write/submit a near-duplicate of another mod just because the original author up and left ;)
Like i said, a clean way for mod abandonment would be desirable, but I don't the team can be expected to pick it up with all the other responsibilities they carry, and the core distribution. But i don't think its something we can *force* on authors, option or otherwise. It would be of questionable legality and would be more likely to push mod authors away, I feel.
A voluntary option to allow another to take over should you not be able or willing maybe to continue would not break any law as such.
Even if it was to a seperate link or e mail telling the mod owner that they are giving their approval for a third party to update a modification should they be willing to do this.The SMF team doesnt have to get bogged down in the middle since the permission can only be granted by the mod writer so not involving the SMF team.If they dont want to allow it they simply dont use the option.
It would also allow mod writers to work more directly with each other and allow those who want to take over some of the work a chance to do so.This to me would be more flexable when it comes to old mods left on the mod site.
Well I like the current system, how multiple people are allowed to edit the same mod. That would kind of prevent it in the future, as long as we each have friends who we trust here.
Oh, and when was the last time mods were moved to the "Archived" section? Should any outdated ones, like from 1.1.4 back, that haven't been updated be put there? That might help a bit, to let us know which mods might need to be remade...
In my personal opinion, SMF shouldn't even be handling 3rd party mods. Mods and Themes should be a separate part from SMF and not even handled by the Team. The team has enough work to do by supporting the forum itself. This is in my mind, a very big reason we don't have any big third party mod sites. Why start your own when SMF is already doing it all? I don't think adding a permission for someone to be able to edit someone elses mod is a viable solution. Its not a contract of any kind just checking a checkbox. That leaves too many options or loopholes for someone to say that they didn't mean to check that checkbox or something. There could be a million excuses for people to cause trouble over these types of issues, and SMF should keep ALL HANDS OFF when it comes to any issues with other peoples licenses.
/me surrenders!
And I'm guessing it's not viable or acceptable or legalresponsibility-able to move all of the mods to a new 3rd party site now... it would've had to be done at the very beginning.
@Yoda, look at my suggestion: http://www.simplemachines.org/community/index.php?topic=280082.0
Quote from: YodaOfDarkness on December 13, 2008, 04:39:53 AM
/me surrenders!
And I'm guessing it's not viable or acceptable or legalresponsibility-able to move all of the mods to a new 3rd party site now... it would've had to be done at the very beginning.
So, in the actual spirit of the topic, what would it take for somebody to start a third party mod site where mod and theme developers could voluntarily* post their mods and possibly have an active third party environment?
Think of it this way -- What's stopping you, for example, from creating such a site?
* It's very important that any third party development listings be voluntary. In the past, people have tried to download all the mods and make their own mod sites, but without anyone's permission to distribute the mods.
QuoteThink of it this way -- What's stopping you, for example, from creating such a site?
Bandwith? :P ;)
Confidence!
The main thing that troubles me is that there are tons of mods on SM.org, and I doubt many new mod developers would waste their time adding mods to a new site. There's also the gazillion mods that are orphaned and couldn't be moved, since the authors only gave permission to SM.org to ditribute it when they uploaded it, not some fancy schmancy new place.
So if that could be reconciled... I wouldn't undertake the project all myself to try to launch it, but I'd certainly work hard on it if a few other people would do the same.
Quote from: YodaOfDarkness on December 13, 2008, 12:13:27 PM
Confidence!
The main thing that troubles me is that there are tons of mods on SM.org, and I doubt many new mod developers would waste their time adding mods to a new site. There's also the gazillion mods that are orphaned and couldn't be moved, since the authors only gave permission to SM.org to ditribute it when they uploaded it, not some fancy schmancy new place.
So if that could be reconciled... I wouldn't undertake the project all myself to try to launch it, but I'd certainly work hard on it if a few other people would do the same.
Very good. I wouldn't be so sure that new mod developers wouldn't want to add their mods. It depends a lot on the environment. Some mod authors do some good work, but get jaded by the requirements of the SMF mod site, for example. Perhaps that would be a good audience of mod devs to target? Some mod authors want to make their mods commercially available, or include advertising text, or other things that simply can't be done on SMF's mod site.
Do you think there's any possibility that the devs here would share some of the code behind the mod site? That way, we wouldn't have to reinvent the wheel...
I'd be willing to help you out with that, Yoda. As an individual, not a team member.
I can possibly help too Yoda, it has always been in my interest to do such a thing.
Orstio - I see you own SMForge.org... and possibility of using that? Dragooon sent me a PM titled "SMF Forge", so I looked up the availability and saw you own the best url for it ;)
We seem to have plenty of third party SMF sites:
www.tinyportal.net
www.simpleportal.net
www.smfthemes.org
www.smfforfree.com
www.smfhacks.com
www.ezportal.com
www.smfarcade.info
www.smfads.com
Those are just the english ones I can think of off the top of my head. Now of all of those who have heard of them?
If there is no 'marketing' from the SMF side of things or a need for them. Then they will die. With SMF being the 'one stop shop' for all things SMF (Core, themes, mods) how would a dedicated third party hub for mod/theme developers help the third party growth?
I think 'we' as SMF allow quite a lot of freedom from our mod/theme developers. We give them guidelines, tips and direction. Then we give them a forum to host and spread their creation to the masses.
I could open a SMFdevelopers site tomorrow. Have a front end and even use the available mods to make a download, blog and portal system for them to communicate to the SMF community and support their creations. But who would come? Who would use it? What added benefit would it be, other than a more relaxed environment to have a mod/theme available for download.
But possibly if you build it, they will come.
and that's the conclusion we came to in private discussion... it's already splintered out, so there's no real point in creating another one.
The only thing I see with those is that they either promote a single mod or a single developer (or development group)'s mods. Just an observation. Well, except for smfthemes.
Well a single mod or single developer is still a branched third party development, which I assumed was the point of this thread. It wasn't for a duplication of the things we have here, but to facilitate a growth in 3PD's.
But strange enough the XOOP example given earlier of their 3PD's, 3 out of the 5 site mentioned are no longer active and 1 of them is just a language specific support 'mirror' of the main one. Which we also have for various languages.
But I wouldn't say it's splintered out, I would say that at least 90% of people searches result in the single location for their SMF needs, and that is here.
I'd like to apologize up front, because as I wrote this some of my frustration with SMF code turned it into more of a rant than I had originally intended.
Old topic but I figured I'd just give my opinion seeing as I actually work a lot with SMF - or rather, against SMF. Because working with SMF code is a battle, and we're not on the same side.
To reiterate a point made I think was very valid. "The problem with SMF is SMF itself"
You say you strive to modularize it and make it more API like, but I'm running SMF 2.0 RC1-1 and I honestly don't see this. You just have to look at ssi.php to see my point, this is the supposed file for integration yet it sets no less than 32 global variables and include 6 files outside of the settings file.
This isn't integration, it's building stuff on top of SMF - and that's the totally wrong way of going about it. The forum is not a central part of a site - at least not for anything serious - if you think like that you doom your software to be used by 12-year-old and "install and forget" type of people. If you want developers to use it then a shift in programming methods needs to happen with SMF developers. You need to seriously reconsider your entire codebase. Usually I'm not a guy who will rewrite things because you just end up redoing the bugs you already did once, but I'll make an exception for SMF. Start over, scrap PHP 4 support, (seriously, not even the php devs support it any more, forget about the people who are still running it) and work on a code structure that will allow people to integrate SMF into their software, not the other way around.
That's not to say SMF shouldn't offer stuff such as user system and calendar, but it should work perfectly fine using info given to it by another system. Naturally this info would have to be in a specific format, but so long as a programmer doesn't need to include a butt load of your code to use it then it won't be a problem.
A lot of my pet-peeves and cringe-worthy things about SMF actually shows in the SSI file.
$smcFun array with links to functions is just about the most stupid thing I've EVER seen, and I've seen a lot of stupid things. You hide the functions you use in an array so that I have no idea where the hell this function is defined.
Also it seems SMF is re-implementing php functions as in "$smcFunc['strlen']".
SSI is practically a joke, if I want my site login to be the same as my forum login then I don't want to include 2,000 lines of SMF code, I want a simple class I can instantiate, feed a mysql resource link as well as user info to a method and then have that class do what it must.
At this point in time it's impossible to do with SMF, at one point you had a smf_api.php file going which was a step in the right direction. I basically took this and started maintaining it myself to do what I needed it to do without including all of the SMF code - sadly, you've abandoned this.
Since I got off-track and repeated myself a bit I'll just reiterate my points:
- Realize a forum is a part of a site and not the site itself. It should be treated as such.
- Forget about PHP 4, it's old, it's not supported and it's horrible.
- Start over. Restructure code and API and modularize it, in a perfect world none of your modules would depend on the core itself, that way it can easily be included in any other project and used.
- NO GLOBALS! Ever!
So in my opinion, get SMF 2 out the door and then start on SMF 3 from scratch. Then I could see myself helping out with code contributions to the core and via mods - but right now? No chance in hell I'd spend the time required to even understand SMF code.
Mostly valid points, that.
Though I'm not a rep for SMF, I would argue the following:
- Globals have a place. Just as Goto does. Not all styles of programming support it, not all programmers like it, but there is a place for them.
- A forum can be the entire site itself. Or it can be part of it. Like everything else it depends what you're trying to do. The exact same argument holds for phpBB3 actually. I personally think SMF does the balance fairly well with SSI.php
- I'm currently building an MMORPG that uses SMF for the forum and also to handle all the user authentication. The 2,000 lines is actually smaller than some of the auth classes I've seen, including Zend Framework's.
- If modules don't depend on a core, they by definition have to redo some of the stuff the core does.
Globals never have a place, they make it impossible to use unit tests and you have no clear point of definition, basically you have no idea what data you're working with or where it comes from, they are a relic from the past and should not be used in any modern code.
A forum can be the entire site yes, but not for any serious project, the sort of developer who might create quality mods for a forum would be unlikely to have a forum site only, usually the type of people who run those projects are people who can't create a product themselves and thus rely on scripts other people made. Thus why I feel it's relevant to this topic as they're specifically asking for ways to make themselves more attractive to third party developers.
As for the 2,000 lines of code, it was a guestimate to the lines of code that didn't deal with the actual function (in this case user authentication) but rather with various other stuff such as templating, sessions, security, permissions etc. In actuality, the number is far, far larger as subs/load.php alone is 2500 lines. Regardless, citing one bad example as a valid reason for bad code is not a really good argument. Zend Framework is not the pinnacle of good code. :)
As for the modules not depending on the code, you have a point, except I'm in favour of a minimal core that doesn't really do anything but direct code flow to the right parts. Think of it in a layered way, you have a model that analyses the url to determine which action to take, then loads a controller to do so, that controller then loads the various modules and loads the forum as appropriate.
If a module then only depended on other modules then they should be loadable from outside the forum framework without too much fuzz and the various bridges to other sites and scripts would merely be to define a new module loader.
I'm by no means saying it would be easy getting a system in place like this, but it's definitely not impossible.
I have yet to see any sufficiently large piece of code that doesn't use globals at all in any way shape or form (other than globally declared classes). I can give you one excellent reason for globals in the case of SMF though - performance. It would be interesting to see what the SMF developers make of my take on the design decision.
I see it that if you have data that persists for the life of the script's execution - i.e. for the entire page generation, putting into a global scope for that script makes perfect sense. So when we initialise we populate $context with the data of who the user is. If we objectify everything we would logically need to make a User class and make the current user a property of an instance of that class. Then we have to pass the property of that class any time we need to use it, meaning that every time we do a function we have to be sending that data between functions. This will be slower than calling it into scope from outside when you do it a lot (i.e. more than once)
Regarding forums being the entire site, I know of some places where it is by far the main part of a site, and everything else being a bolt-on to it, some that support people very comfortably in fact. It just depends on the project and its aims. But take a look through Showcase - the number of people for whom the forum is the site is the forum is quite surprising.
Actually, under the hood SMF is fairly modular - a check of the Function DB would confirm that is the case.
Regarding the large size of includes; agreed SSI is not as minimal as perhaps it could be, but it has to be a fairly generic thing lest you have a module for each part (one for authentication, one for getting posts, one for getting user details) and moving that to the SSI user-developer to implement. In fact, though you say ZF is not the pinnacle of coding (which it isn't), the manner of objectification you're suggesting - giving each specific area its own module is precisely how ZF is arranged. Whether the individual lines of code are poor, the structure is that which you are arguing in favour of.
2.0 is already a fairly big rewrite versus 1.1 - what would you expect to see in 3.0 that completely rewrites 2.0?
You're severely underestimating the power of the CPU, the speed difference between the two programming styles is measured in micro seconds and you will not lose many requests per second. Personally I find the tiny speed degradation worth the gain you get in ease of programming. Besides, you're optimizing in the entirely wrong area, most likely 90% of your script execution time will be spent waiting for the file system of the database. If you want to optimize things then cache things that actually take up time, don't micro-optimize. Besides, premature optimization is the root of fluffy and cute.
I'm not saying that forum-only sites doesn't exist, I'm just saying they're rarely run by the type of person who consistently produce their own code and would be willing to help out with third party addons to SMF.
As for Zend Framework, personally I believe they abstract things a bit too much and use too much magic with cross includes and a much too much complexity. That doesn't mean they aren't going in the right direction, pretty much any PHP framework these days uses a MVC structure, Zend, Solar, CodeIgniter. It doesn't really matter, in the end they all use OOP code since it promotes readable code that's modularized and easy to make heads and tails of.
Actually, time of execution in SMF seems to be about 50/50 split according to the questions on it; and where it's skewed towards the DB it's usually because the DB isn't tuned to best performance, not because of the application. I wasn't thinking so much of the 1-or-2 executions, I was thinking of such things whereby if every function call and every loop is referring to a passed-by-reference variable (which it always will be with strings, for example) it's going to be more than a little speed degradation versus bringing things into scope from global.
The argument of OOP vs algorithmic is going to rage far longer and wider than here, and if it's something you're really passionate about, a debate in Coding Discussion is the way to go; for example, take MediaWiki - that's much more OOP styled (and has global vars!) and I'd argue that it's harder writing a mod for that than it is for SMF.
I see where you're coming from, but the rewrite you're talking about is even bigger than SMF 1->2, and I'm not convinced a rewrite of that magnitude would help a 3PD any more than leaving it as it is now - nor do I think the developers of SMF are.
What would a 3PD want from SMF in terms of being able to integrate? Off the top of my head the really big things:
- Ability to use SSO - doable via SSI.php
- Ability to retrieve posts - doable via SSI.php
- Ability to display current member information - doable via SSI.php
There are more - I know there are. But each time SSI.php covers it, and if it doesn't it's not a huge leap away to get it. I'd hate to use multiple classes for these tasks that, for me certainly, go together. In fact, it definitely goes together - if you want to get the latest posts you need to know who is logged in, and thus what posts they can see. Thus you need each time to depend on that auth system, which means you instantiate that class each time.
Anyway, we're getting off-topic, the debate here was about restructuring SMF to support 3PDs; SSI.php and SMF_API are the two cornerstones thus far to doing that. As a 3PD developer how would you expect to see SMF? Saying it should be OO is fine but it would help to have some idea of what you're envisaging since that can be put forward as a suggestion for 3.0.
I think I argued what I would like SMF 3 to be fairly well, if you do not yet at least see what I've suggested what I'd be interesting in writing mods for then I don't think I can explain it well enough, because I certainly don't know how to explain it differently.
I see the general idea you want, you want SMF to be object oriented in design. What I'm trying to get at is how you would want it to be structured at a deeper than "just OO" level.
I mentioned MediaWiki; it's 'object oriented' in design but just about everything lives in the User object. How would you as a 3PD developer want to find SMF? A single master User object with every method attached? Multiple objects? One per major module of SMF? (e.g. DB, User, Post, Board, Template) or something else entirely?
The key is separation and isolation of objects, if everything lived in one object you might as well not use object orientated programming. Ideally each function would have it's own module, so for example a class would exist for user functions such as authenticate, login and logout amongst others. This module would then depend on a MySQL object (which would inherit it's structure from an abstract SQL class) and a validation object.
Each object would be loaded by a central loading class so you could cache already loaded objects and use dependency injection with modules, that way you can easily unit test the whole thing.
Done right the bridging with other systems would involve writing your own version of the loader (possibly extending an abstract class that defines what must be implemented), if you wanted to you could then inject your own code instead of the SMF code so long as it implements the proper methods.
It's not something you cook up on the spot, it takes a lot of planning and I'm honestly not inclined to work up a system like this for something that probably won't happen, I don't have that many hours to throw away.
I just meant a three or four line overview of how you'd expect to see it, not a complete overview diagram of intermixed modules and dependencies, but I have a better idea where you're going, and in an ideal world it might help. Though I would still worry about performance - lazy loading modules is not always as/more efficient as/than always loading, when you have filesystem and bytecode caches in play at least.
The biggest problem now is that there are bridges to other CMSes (e.g. Mambo, Joomla) that would need to be completely rewritten to support such a move; you might as well start over and not reuse the SMF base in that case.
Thank you for your input and discussion, it's been interesting to see how others perceive the code base.
Indeed thank you Arantor and Ensiferous for this discussion.
I think it will obviously need some time to digest. I just wanted to say these sorts of posts on the structure of smf are not superfluous.
At the moment the devs are working towards getting 2.0 completed, and then obviously we will begin further planning for the next iteration of SMF. So this is obviously the right time to propose/discuss these sorts of changes.
(although we might want to break off these responses into a separate topic on the future structuring of smf architecture/code.)
As for PHP4, we were already working on 2.0 before php4 got officially mothballed, so it didn't make sense to strip php4 support, since support required only a few compatible functions under the current coding style. I don't think any decision has been taken about support for it for next smf. (I personally wouldn't be against dropping php4 support).
I would quite like a better MVC approach for smf, although MVC and OO aren't necessarily mutually exclusive. Its just that alot of projects doing MVC have done it in a non OO way.
I for one have opted to be notified for future posts in this topic, and I know a post has already been made about this topic to the attention of the developers. So please continue ;)
/me goes back to bugfixing
Quote$smcFun array with links to functions is just about the most stupid thing I've EVER seen, and I've seen a lot of stupid things. You hide the functions you use in an array so that I have no idea where the hell this function is defined.
Also it seems SMF is re-implementing php functions as in "$smcFunc['strlen']".
As far as I know, some functions are reimplemented if UTF-8 is enabled, to support UTF-8 on specific PHP configurations. And one use of the array is for the database implementation - SMF supports multiple DBMSes (MySQL, PostgreSQL, etc.) each of which use different functions. Things like $smcFunc['db_query'] will actually go to the correct function (although, I'd personally use classes that inherit from an abstract class, then instantiate the correct class via a factory method). I was actually saying to someone a while back that an object-oriented SMF would be nice, but it'd be a BIG rewrite that'd require a lot of effort. It'd be nice to see, one day :)
And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they foumd it too hard to integrate :(
Quote from: Daniel15 on June 05, 2009, 12:14:56 PM
And indeed, I agree with you on a few points. I've seen a few sites migrate away from SMF because they found it too hard to integrate :(
I came to the point where I had phpBB3 installed and everything converted over because SMF 1.1.9 performed so horribly bad with a 750k memberbase in certain cases such as banning. SMF 2 RC fixed that though so I opted to save my time on integrating phpBB3 and just adapt my own smf_api.php to work with SMF 2 - but it was close, real close.
In the case of $smcFunc the idea is that you don't actually need to touch how it's defined; it's an abstraction to handle the different database backends, and is done so in a way that doesn't require creating three classes then lazy-loading and declaring. It's also PHP 4 friendly for the reasons above.
I would suspect the roadmap would be that for 3.0 to strip PHP 4 support and move some of it towards an OO style.
Two big hooks for 3PDs will be some variation on SSI.php and SMF_API. The former isn't geared to full blown app development with SMF; it's designed as a general purpose slot-in to integrate into sites for those people who aren't strongly technical but can manage a little PHP. For example a news feed on a simple site, or to present the login across a wider site and rely on SMF to handle authentication.
SMF_API has more potential for 3PDs in that regard; it's intended to be lighter-weight, and more readily able to get under the hood a bit - but it's not current for 2.0 I believe. That should be the first step, I think.
A third big hook is the codebase itself. The function DB has gone a long way towards simplifying how to access the codebase to do big things with it - plentiful, good documentation never hurt anyone - and I won't deny a clean-up could be used.
What would be really good is for whatever structure 3.0 might have is for it to be posted with a structure diagram and a guide to how it might look structurally so that we can all help hammer it out. Whatever, I think it's going to be a virtual rewrite rather than a code shakedown/restructure.
$smcFunc doesn't just handle databases, if you look at its coding. It's scripted to handle much more than that.
Quote from: Daniel15 on June 05, 2009, 12:14:56 PM
Quote$smcFun array with links to functions is just about the most stupid thing I've EVER seen, and I've seen a lot of stupid things. You hide the functions you use in an array so that I have no idea where the hell this function is defined.
Also it seems SMF is re-implementing php functions as in "$smcFunc['strlen']".
As far as I know, some functions are reimplemented if UTF-8 is enabled, to support UTF-8 on specific PHP configurations.
To expand on this, not all PHP functions are utf-8 compatible, which is why they need to be rewritten. There are no lines like
$smcFunc['strlen'] = 'strlen';;)
Not sure if this has yet been stated, but it is pretty important I think it wouldn't hurt to restate it XD.
Software previews... or something like that. I know SMF releases beta's and RC's, but for certain projects, it requires more than that. Like TinyPortal (Though the creator of that is/was a SMF dev :P) and SimplePortal which use SMF in many ways is a tough thing to do and can take lots of time for the developers to get it properly working with the new version. Developers might get their projects working with SMF beta's and RC's, but each time a new version is released, a lot has changed and then their product cannot be used by clients for awhile until they have it working with the new version.
Basically, these developers need to be able to see what and how SMF is changing before a version is released. I don't mean SMF tell them first, wait a week or more, then release it. But in some way allow third parties to have some kind of access to know more of what is changing in new versions of SMF in a day to day basis.
Basically what I am saying is kinda like what Microsoft and Apple do... When they are developing the next version of an operating system, they give developers access to SDK's earlier than others, sometimes even giving them the whole operating system so they can test on it and what not. It would be a lot for SMF to do, but you could have some kind of team to do something like that.
So yeah :)
Sorry if some things didn't make to much sense... I am sitting in a 90 degree room .-.
Yes, I've seen that in other projects as well. It requires some management -- the same as keeping an active list of beta testers. You don't want people signing up for access to the latest SVN just to have it, for example. They have to be actively developing a plugin/mod/extension.
It is a very good idea, as it also gives 3PDs an incentive to stay active in their development.
Yeah. That is always the thing... these things have their ups and downs. But if you had a team which could manage that instead of having the SMF dev team (Who should be hard at work developing SMF XD) handle it, it would be workable. Probably slow at first, but after time, it would get better.
I like this idea, and hope it can be something of. But I fear as with earlier projects, that time and manpower escapes it being set in motion.
Don't forget that Charter members do get it ahead of the rest of us, but I can see what you're saying. You'd almost have to hand out a form of NDA to ensure it doesn't get distributed ahead of schedule.
Quote from: aldo on July 03, 2009, 10:27:21 PM
Not sure if this has yet been stated, but it is pretty important I think it wouldn't hurt to restate it XD.
Software previews... or something like that. I know SMF releases beta's and RC's, but for certain projects, it requires more than that. Like TinyPortal (Though the creator of that is/was a SMF dev :P) and SimplePortal which use SMF in many ways is a tough thing to do and can take lots of time for the developers to get it properly working with the new version. Developers might get their projects working with SMF beta's and RC's, but each time a new version is released, a lot has changed and then their product cannot be used by clients for awhile until they have it working with the new version.
Basically, these developers need to be able to see what and how SMF is changing before a version is released. I don't mean SMF tell them first, wait a week or more, then release it. But in some way allow third parties to have some kind of access to know more of what is changing in new versions of SMF in a day to day basis.
Basically what I am saying is kinda like what Microsoft and Apple do... When they are developing the next version of an operating system, they give developers access to SDK's earlier than others, sometimes even giving them the whole operating system so they can test on it and what not. It would be a lot for SMF to do, but you could have some kind of team to do something like that.
So yeah :)
Sorry if some things didn't make to much sense... I am sitting in a 90 degree room .-.
+1
Beautiful idea. Great for the large and popular mods that often come head to head with the bugfixes and changes in SMF, which causes delays for users, especially with pre-release versions.
If SMF had a quicker release cycle it really wouldn't matter much. SMF has a great platform for notifying administrators of new updates, (although a notice on index wouldn't hurt) coupled with a more modular structure in the future (one can at least dream) SMF can basically update modules with small feature additions or changes instead of having to wait a year for a huge update. That way updates required to mods would be minimal at best, especially if each module provides an API and make as few changes as possible to that.
Giving out early releases would be a band-aid solution and would involve a lot of work with no real gain, IMO it's yet again a question about code structure.