What can we do to help grow our 3PDs?

Started by Orstio, May 07, 2008, 07:36:24 AM

Previous topic - Next topic

Dragooon


Dannii

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.
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

Dragooon

Well, if SM.org doesn't wants to promote them I guess thats fine.

bloc

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..?

Orstio

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

bloc


karlbenson


SneakyWho_am_i

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.

Johno69

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.

steighan

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
"Frequently wrong, but never in doubt"

Eliana Tamerin

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?
Do NOT PM me for support.

SimplePortal 2.3.6 is OUT!
SimplePortal Project Manager
Download | Docs
SimplePortal: Power of Simplicity!

Grudge

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'm only a half geek really...

Eliana Tamerin

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.
Do NOT PM me for support.

SimplePortal 2.3.6 is OUT!
SimplePortal Project Manager
Download | Docs
SimplePortal: Power of Simplicity!

bloc

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

Eliana Tamerin

I thought that's what Joomlaboard was. :P
Do NOT PM me for support.

SimplePortal 2.3.6 is OUT!
SimplePortal Project Manager
Download | Docs
SimplePortal: Power of Simplicity!

Orstio

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.

bloc

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?

steighan

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
"Frequently wrong, but never in doubt"

bloc

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.

steighan

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
"Frequently wrong, but never in doubt"

Advertisement: