What is the future of phpBB????

[code reader]

development is fubar? Why? Too slow?

when 3.1 will eventually go out (if it ever will) many of the new stuff it will contain are things developed by people that are no longer around.

i do not think this is a sane way to run a project. when developers turnover is faster/shorter than the release cycle, i do not think it's a viable development model.

personally, i do not pay close attention to phpbb development any more, but i remember that at one time or another, the project considered participating in google's summer of code (aka gsoc).

a (theoretical) young and enthusiastic CS student that might have participated in gsoc 2009 for phpbb would have, no doubt, work on some 3.1 or 4.0 related project (3.0 was released in 2007, and i can't recall any meaningful feature worthy of gsoc developed for any 3.0.X release).
in the meantime, this theoretical person would have graduated and either started working in a "real" company for real salary, or continued on as graduate student. no matter how good/excellent/brilliant his or her phpbb code might have been, it's still buried somewhere where the sun doesn't shine, 4 years later.

how can anyone see this as a viable development process of a live project?

again, i am not trolling and not gloating - it is with some sadness and disappointment that i say this.

some of us still remember the dysfunctional state this project was in after phpbb 2 came out, and psoTFX was the leader.

The whole thing was painful. Paul stepped down (or rather, stormed out, slamming the door and shouting), AcydBurn took over, the project got unstuck, and eventually phpbb3 was released.

phpbb3 have set new standards in forum software: even though it's less performant than most other packages (and i have good reasons to think it's less performant than 2.0), the brilliant decision to do the security audit, and the excellent job the auditors did, made it the safest system for its time, better or equal to any other forum software out there.
it had very capable and flexible permission system (albeit complex and cumbersome to use), it added almost all the essential pieces that were missing in 2.0 (unicode, attachments, hierarchical forum structure, flexible permission system, moderated posting process, and modernized CSS based page design) - the only significant last missing piece was what plagues phpbb3 ever since: lack of a good plugin/hook system, forcing all extensions and enhancements to remain the same abominable unsafe hacks (or "mods", in phpbb nomenclature) phpbb2 was known for.

this process took slightly more than 2 years (psoTFX removed himself as an obstacle in 2005, and phpbb3 "gold" came out towards the end of 2007, iirc). during those 2-3 years, the team was very stable.

i have no idea when 3.1 will eventually materialize (in the phpbb culture, the prime directive seems to be "never ever ask any question about timetable/schedule/plan"), but assuming it _will_ materialize eventually, there is real risk of it being too little too late (actually, the "too late" part is not a risk but a certainty. the "too little" part is a very real risk).

i went on a long tirade here. as i write this, i am not sure i'll press "submit". if you read it, i guess i did...

peace.

[DavidIQ]

personally, i do not pay close attention to phpbb development any more, but i remember that at one time or another, the project considered participating in google's summer of code (aka gsoc).

I know you sort of alluded to this but with this comment it is very apparent you definitely don't know anything about what's going on here which makes much of your long post unreliable. phpBB participated in GSoC last year and is participating again this year after very good results last year.

[wGEric]

His point is still valid. People who have contributed haven't seen their work be released yet. Igor and Oleg are two that I can think of off the top of my head.

[DavidIQ]

His point is still valid. People who have contributed haven't seen their work be released yet. Igor and Oleg are two that I can think of off the top of my head.

That part is unfortunately the current state of affairs. There is a bit of a push to make 3.1 ship-able at least to Alpha/Beta so hopefully that will soon be made available.

[code reader]

I know you sort of alluded to this but with this comment it is very apparent you definitely don't know anything about what's going on here which makes much of your long post unreliable. phpBB participated in GSoC last year and is participating again this year after very good results last year.

i freely admitted that i do not keep close watch at what's going on in the project any more.

however, your assertion that these projects had "very good results" is patently false. i am not saying you are lying - it is much more likely that you lack basic understanding what "good results" mean, which is not very surprising for someone who lived within the phpbb bubble for as long as you have.

in gsoc world, "very good results", or even "moderately good results", or even "acceptable results" mean having the gsoc code becoming part of the project's production release. without knowing a single thing about the projects you mentioned, it is clear that this did not happen with them - there are no "production releases" in phpbb world, except the 3.0 bug fix cycles.

personally i think that for google to allow any student to participate in gsoc for phpbb points to poor judgement that shows basic ignorance about the state of this project.

what would they learn? the goal of gsoc is to get students familiar with open-source projects, life-cycle and development methodology. why would anyone want to take phpbb as an example they want anyone to follow?

first and foremost, phpbb has to lose the failing "it's ready when it's ready" attitude.
this can only work when things actually becoming "ready" within a reasonable amount of time.
with all his failing, abrasive attitude and amaturistic code, psoTFX was able to get phpbb2 "ready" in less than a year, so "it"s ready when it"s ready" kinda sorta worked (even though it took phpbb2 about 14 releases to become anything close to "ready" in reality - iirc, the first release that could be considered anything other than RC was 2.0.14).

this attitude failed miserably during the painful years between phpbb2 release and psoTFX leaving, and i do not see it as such a brilliant success now.

every single successful open-source project i know of have long converted from "decide on content - release will happen when it's ready" attitude to "decide on release schedule - features will be merged in when they are ready".

the more successful model gives developers motivation to bring their little projects/features to "release worthy" status. if phpbb would have used this model, it was possible to look at those gsoc projects and have a clear and simple criteria to decide whether the assertion that they had "very good results" is true or not: the criterion would have been: "were they merged into the production branch"?

as it is, these projects are buried somewhere where the sun does not shine. it's beyond me how can someone think of this as "very good results".
personally, i think it's very irresponsible of google to allow phpbb to host gsoc projects, as long as this project stick to the "it will be ready when it's ready" failing attitude.

peace.

[Frug]

phpbb3 have set new standards in forum software: even though it's less performant than most other packages (and i have good reasons to think it's less performant than 2.0), the brilliant decision to do the security audit, and the excellent job the auditors did, made it the safest system for its time, better or equal to any other forum software out there.
it had very capable and flexible permission system (albeit complex and cumbersome to use), it added almost all the essential pieces that were missing in 2.0 (unicode, attachments, hierarchical forum structure, flexible permission system, moderated posting process, and modernized CSS based page design) - the only significant last missing piece was what plagues phpbb3 ever since: lack of a good plugin/hook system, forcing all extensions and enhancements to remain the same abominable unsafe hacks (or "mods", in phpbb nomenclature) phpbb2 was known for.

Must say I agree with all of this.

I don't think it's too negative. It's important that opinions get voiced as long as they try to be objective.

The rest I'm not so sure. You sound a bit spiteful toward it, but it's misplaced. If you want a failing attitude, look no further than "it's free so don't complain" as an excuse for slow/lacking features. It's been said here before, and that's the worst... but it's sadly true, there's no point getting mad.

Right now I know of nothing as good as this that's free. If phpbb lags behind something obviously better, I'll switch, and either the project will improve or it will dwindle. But don't get mad about it. I'm sure the GSoC participants still learn plenty.

[code reader]

The rest I'm not so sure. You sound a bit spiteful toward it, but it's misplaced. If you want a failing attitude, look no further than "it's free so don't complain" as an excuse for slow/lacking features. It's been said here before, and that's the worst... but it's sadly true, there's no point getting mad.

Right now I know of nothing as good as this that's free. If phpbb lags behind something obviously better, I'll switch, and either the project will improve or it will dwindle. But don't get mad about it. I'm sure the GSoC participants still learn plenty.

just to clarify: i have no ax to grind, and i don't think i'm spiteful (although i'll admit my criticism is harsh).
GSoC aside, my main point was that when 3.1 will be eventually released (and i do think it will be released eventually, although i would not put money on date - right now 2013 seems highly doubtful, and even 2014 is far from being a safe bet), many, or even most of the people who developed the bulk of its content will have already left the team.

at this state of affairs,talking about 4.0 and investing any kind of effort in it cannot be considered a reasonable thing to do.
this basically means that anyone who spent any effort on 4.0 to date, was really engaged in pure and simple exercise in time wasting.
this is meaningful, as many people have invested huge amount of time on 4.0 - making suggestions, debating them, and even writing some code.

at the risk of being a PITA, i'll repeat my main point: in order to become viable, from a future looking point of view, the project must abandon the "it's ready when it's ready" attitude and adopt a different mode of operation: predictable release schedule, where the unknowns are not the release date, but rather the precise content of each release, such that "it's ready when it's ready" relate to features rather than to releases. any contributor who wants their contribution to make its way into the release ( which is the ultimate motivation of any open-source developer) will be responsible to make sure their contribution is release-worthy.

currently, no matter what effort any contributor makes, they can't get their contribution into the release, because there is no such thing as a release, there was no such thing since 2007, and who knows when will it eventually be.

so no, i am not spiteful - i actually like this project, and in the distant past even made some moderate contributions to it, with bug reports, support, and even some very modest pieces of code.


SOME POSITIVE PROPOSITIONS
==========================

("positive" in the sense that i say what i think should happen, instead of just whining about what i think is wrong...)
So here is what i think this project should do:

1. stop any effort or discussion about anything other than 3.1: lock the "4.0" forums here, and declare complete cease and desist any 4.0 effort that might be still happening
2. create a "3.1" branch with 0 development - only stabilizing and bugfixes are allowed
3. stop spending time on new stuff (on another thread i noticed a "new template engine" discussion - nobody from the team core should be engaged in this kind of activity at the moment
4. declare the "3.1" branch as "alpha", and do whatever it takes to bring it to "beta" level, and then to "rc" level, and then to release
5. ideally, commit to some specific dates. i am not talking about something like "July 17", but it would be nice to hear something like "we are shooting for RC version before the end of the 2013". it is possible to be aggressive but not overly optimistic. how nice it would be to promise "RC by EOY", and then manage to squeeze RC2 for Christmas? even if it'll take RC4, RC5 or RC9 before actual release, this is the way to go. some people here still remember what a huge morale boost it was when 3.0 RC0 came out. even though it took another 6 months and 8 RC's, these was exciting time, full of activity, compared with the previous gloomy 5 years. let's see an RC!
6. once 3.1 is released, declare a predictable release schedule, with predictable points in time for predictable events: e.g., if the release cycle is 3 months, there should be one month "merge window" for new features, one additional month for serious bug fixes and refactoring, and the last month dedicated to RC cycle with testing and bugfixes.
7. as early as possible in the life cycle of every new feature branch, declare which release it aspire to merge. at the beginning of every merge window declare which of the targeted features are planned to actually be merged (based on their status and stability). don't hesitate to bump a feature that does not meet expectations to future release.

peace.

[Black Antitoon]

I have total respect and appreciation for the work of the devs, but I must say that I have the same feeling as code reader about the status and the future of phpBB. I know how hard it is to give ETAs with software development, and I am not blaming anybody, but the current strategy so far isn't working terribly well. I can also recall some time (years?) ago reading an announcement announcing a different and more dynamic release schedule (and the renaming of phpBB 3.2 to 3.1). Where has this gone?

With respect.

[imkingdavid]

First, I appreciate your concern and for taking the time to write all this out.

at the risk of being a PITA, i'll repeat my main point: in order to become viable, from a future looking point of view, the project must abandon the "it's ready when it's ready" attitude and adopt a different mode of operation: predictable release schedule, where the unknowns are not the release date, but rather the precise content of each release, such that "it's ready when it's ready" relate to features rather than to releases. any contributor who wants their contribution to make its way into the release ( which is the ultimate motivation of any open-source developer) will be responsible to make sure their contribution is release-worthy.

That is the plan. After 3.1 is released, I believe the goal is to have a more time-based (but still flexible) release cycle rather than feature base (i.e. rather than "we'll release after features x y and z are done", it would be "in X months a new version will be released with whatever is ready"). That being said, there will still be no hard deadlines on development, so even if releases are more often, that doesn't mean there will be several significant changes each time.

stop any effort or discussion about anything other than 3.1: lock the "4.0" forums here, and declare complete cease and desist any 4.0 effort that might be still happening

At this point, I think 3.x is going to eventually become 4.0. The original idea with 4.0 was to rewrite the software on top of symfony2. As of now, several components of Symfony2 have already been integrated into the 3.1 codebase, so instead of starting over with a rewrite, effort should be put into improving the current code as well as adding new functionality.

create a "3.1" branch with 0 development - only stabilizing and bugfixes are allowed

A 3.1 branch will be created when 3.1-A1 is released. As for 0 development, you'd need to define what "bug fix" is vs adding things. For example, Twig is currently being integrated in place of our current template system because that will help solve several current and potential bugs, but many would argue that that is going above and beyond a simple bug fix.

stop spending time on new stuff (on another thread i noticed a "new template engine" discussion - nobody from the team core should be engaged in this kind of activity at the moment

As per my previous point, integrating Twig will resolve bugs and give us a more overall stable and reliable, as well as efficient and flexible, template system. We can either keep patching together fixes for specific bugs and wait for more things to break due to those hacks, or we can integrate a widely-used system that is maintained by someone else so we don't actually have to worry about it as much.

declare the "3.1" branch as "alpha", and do whatever it takes to bring it to "beta" level, and then to "rc" level, and then to release

For the record, this wiki page lays out fairly clearly what each step in the Release Cycle is. Beta has a sort of "soft feature freeze", in that the beta version is branched off of develop but new features continue to be merged into develop and it is up to the Release Manager which features get into the beta version. At RC stage, it is a "hard feature freeze", meaning no new features get in.

ideally, commit to some specific dates.

I'd love to. I know it's frustrating that development is going so slowly. But the reality is that it's 6 people on the team, and a handful of other people, but only a small amount are consistently active in contribution. I, for instance, haven't been as active as I'd like because I just started a full time job so I'm limited to a few hours at night to work on this and a few other things. With the lack in human resources as well as lack in availability of the people we have, it is unrealistic to set a date. I'd love to say that 3.1 (at least a beta version) will be ready to go by Christmas, and I think that there's a good possibility given the amount of work we've done in just the past six months, but I don't know how realistic it would be to expect that.

once 3.1 is released, declare a predictable release schedule, with predictable points in time for predictable events: e.g., if the release cycle is 3 months, there should be one month "merge window" for new features, one additional month for serious bug fixes and refactoring, and the last month dedicated to RC cycle with testing and bugfixes.

As I said, that is the plan. The original plan for 3.1 was "let's make a long list of features and not release until they're all done". That was the original feature freeze. As the years went on and the list wasn't shrinking very quickly, it became clear that that was not an acceptable release cycle. So the plan is to have a more regular release cycle, as I mentioned above. I'd go into more detail, but I'm not sure what's been made public yet.

as early as possible in the life cycle of every new feature branch, declare which release it aspire to merge. at the beginning of every merge window declare which of the targeted features are planned to actually be merged (based on their status and stability). don't hesitate to bump a feature that does not meet expectations to future release.

IMO features should be merged as they are ready. I'm not sure we really need an official process for this, except that (IMO) if a release is ~2 weeks away and a feature needs ~3 weeks, it would be acceptable to hold back the release that extra week (but just one week at most, not indefinitely until the feature is actually ready).

As I said, thanks for taking the time to write all this out. Feedback is good, especially when it's constructive and good ideas are explained. The main issue right now is a lack of active contributors.

[DavidIQ]

as it is, these projects are buried somewhere where the sun does not shine. it's beyond me how can someone think of this as "very good results".
personally, i think it's very irresponsible of google to allow phpbb to host gsoc projects, as long as this project stick to the "it will be ready when it's ready" failing attitude.

Again, you are wrong. The work that the GSoC students did was not just thrown away or "buried somewhere" as you seem to be suggesting. You should do a little more research over at github before you suggest things like that and make all sorts of irresponsible assumptions.

As far as the rest of what you've posted goes it seems that you expect the phpBB project to be run like any other average paid development shop and that is simply not realistic and will not work for this project. Sure some of us would love to work on nothing but phpBB but that doesn't pay the bills unfortunately.

We went to github in an attempt to get the community to contribute a little more and be more "open" and that has worked to some extent but has not fully sped things up. This is because things have fallen behind in regards to development work particularly with pull request code reviews. Many outside of development that merely uses the final product is expecting things to be done fast and get upset when they're not. The developers are doing the best they can at the fastest rate possible.