Core vs. Extensions

[code reader]

there are two issues here - i'll relate to them one at a time

The development team will package code into extensions as it sees fit. Control over said code is relinquished (or not) as the development team sees fit.

i do not think this is reasonable. every piece of code should have (at least one) owner. the idea that you can produce code and then "relinquish" it to someone else was tried in the software industry many times (i believe it was the dominant model in the 70's), and was rejected. anyone who "owns" a piece of the core functionality, regardless if it's implemented as "core" or as "extension", is by definition part of the "core development team".

Ripping out features into extensions is a good idea in my opinion, but a different story. The code properties of legacy code (spaghetti code, non-explicit dependencies, lack of tests, etc.) make doing so rather difficult. I personally would suggest to rather spend time on making the extension system itself more robust in the near future.

no argument here: first of all, bad code should be deleted, and replaced by good code, not "ripped out".
i did not suggest to invest heavily in dismembering phpbb right now - my comment was not so much about "what should we do tomorrow morning", but rather "what is the shape of the long-term destination/direction we are moving towards".

i also agree that tending to the extension system itself is high priority, but IMO, the surest way to do so is to try and make sure new development happens, as much as possible, in the form of "extension".
this will help the developers identify any deficiency of the extension system, and augment it - something that's much less likely to happen when they are happily adding more code and more functionality to the central monolith.


peace.

[bantu]

The development team will package code into extensions as it sees fit. Control over said code is relinquished (or not) as the development team sees fit.

i do not think this is reasonable. every piece of code should have (at least one) owner. the idea that you can produce code and then "relinquish" it to someone else was tried in the software industry many times (i believe it was the dominant model in the 70's), and was rejected. [...]

Maybe I should have said "Sole control over said code is relinquised [...]".

I basically see two options (per core extension):

• Development Team wants to have sole control over extension and maintains it.
• Development Team co-maintains extension with other teams.

[EXreaction]

You have the resources to maintain these features in the core, but not as extensions? :S

We do not have the resources to pull the given features out of their tight integration in the core and move them into extensions. Doing so would mean a significant amount of work in that alone, but also in refactoring a large amount of code, writing test suites, etc. A lot of these features discussed have hardly been touched in years and so have required very little work from anyone to maintain.

[wGEric]

The real issue will be with the dependencies and the maintenance of the third parties because with this system the extensions will depends on many others extensions (why not, it could be a good thing) and so, inevitably, an official extension will depend of one future of a third party extension for which the team will have to give support (and maybe maintain this extension themself if the original maintainer stop). If you see what I mean.

Tons of other open source projects do just fine by relying on 3rd party extensions. If the original maintainer stops then you can always fork it if you need to or use something else.

[Nicofuma]

The real issue will be with the dependencies and the maintenance of the third parties because with this system the extensions will depends on many others extensions (why not, it could be a good thing) and so, inevitably, an official extension will depend of one future of a third party extension for which the team will have to give support (and maybe maintain this extension themself if the original maintainer stop). If you see what I mean.

Tons of other open source projects do just fine by relying on 3rd party extensions. If the original maintainer stops then you can always fork it if you need to or use something else.

Examples of important projects which rely to third party extensions for the core/main features?

[code reader]

Examples of important projects which rely to third party extensions for the core/main features?

jquery (specifically, the jquery ui package is 3rd party, and practically all other plugins are, too), mysql (specifically, innodb, arguably the most important storage engine used by mysql, was developed by 3rd party), linux kernel (specifically, device drivers, virtualization, file systems, and almost everything else).
this is just the tip of the iceberg, of course. in open source projects which adopted the "bazaar" model, the line between "core" and 3rd party" is very blurred.

the key phrase here is "rely". arguably, these projects do not "rely" on 3rd party development, but when it appears, good managed projects have no problem fully embracing it, instead of snubbing it with "NIH" attitude (as in, "Not Invented Here")

i do not think this question and answer really belong to this thread, though: originally, this thread is not about "3rd party development", but rather about "some _core_ development should be done using the extensions model", as in "i don't think it's beneficial to equate extensions with 3rd party development".


peace.

[callumacrae]

The real issue will be with the dependencies and the maintenance of the third parties because with this system the extensions will depends on many others extensions (why not, it could be a good thing) and so, inevitably, an official extension will depend of one future of a third party extension for which the team will have to give support (and maybe maintain this extension themself if the original maintainer stop). If you see what I mean.

Tons of other open source projects do just fine by relying on 3rd party extensions. If the original maintainer stops then you can always fork it if you need to or use something else.

Examples of important projects which rely to third party extensions for the core/main features?

Pretty much every front-end project ever.