I suppose a lot comes down to what kind of requirements we have but my personal recommendation is to use D7 rather than D8; the latter has nowhere near the depth and breadth of modules and maturity that D7 has. Also it will be supported officially for as long it takes to get D9 out and judging by how long it took to build D8 it looks like a good 4 years before that happens.

tassos wrote:I suppose a lot comes down to what kind of requirements we have but my personal recommendation is to use D7 rather than D8; the latter has nowhere near the depth and breadth of modules and maturity that D7 has. Also it will be supported officially for as long it takes to get D9 out and judging by how long it took to build D8 it looks like a good 4 years before that happens.

That would be one big "Con" for Drupal: knowing you have to deal with all the breaking changes between D7 & D8. Also, contrary to neverendingo, I believe straightforward and easy theming does matter a lot. Lacking in that dept might not count as a problem solving burden, but it is a big nuisance.
Luckily, Twig can be used in D7 in a futureproof way: http://makina-corpus.com/blog/metier/20 ... n-drupal-7

I think that neverendingo's point was that any system can get the job done in terms of theming because in essence their theming systems do work. The annoyances are due to people being used to one more than other.

Even though I share the same view that the presentation layer is important I think the decision for the kde.org website must be down to the following reasons:

1. How mature the system is
2. How active the community is
3. How established security processes are
4. How configurable to different use cases the system is
5. How easy to support automated deployments and continuous integration is
6. How easy it would be to find developers after the project is delivered

The website is a marketing tool to show our vision and work, to the rest of the world and we need a stable, well proven platform to do that.

Since I see that we won't even consider platforms in other languages I won't say anything more about Django CMS, or other python based platforms. Or any other non-PHP based platforms. No matter how good they are. (dissapointed)

ovidiub13 wrote:Since I see that we won't even consider platforms in other languages I won't say anything more about Django CMS, or other python based platforms. Or any other non-PHP based platforms. No matter how good they are. (dissapointed)

Why not do an analysis of Django with the template in the first post, though?
It won't make a huge difference to me. I'm used to idling in #openhatch and guiding the Python devs that frequently pop up with questions on what they should contribute to

Recruiting difficulty from highest to lowest:
If we go with Django, I will recruit Django devs.
If we go with Drupal, I will recruit Drupal devs.
If we go with ProcessWire, I will recruit PHP devs.

If we go with Django, we might team up somehow with the OpenHatch folks - after all, they already have an outreach platform ready! Django + OpenHatch has a big advantage when looking at tassos's reminder about how we need to excel in outreach.

This discussion needs to be framed to the problem in hand which is to choose a platform to serve KDE's web presence.

Python and django have their merits on their own right and are really cool technologies, but on the Web the prevelance of php is undeniable. Personally I respect the python community very much for tools like fabric and ansinle but still php prevelance means more support, more devs and a lower barrier of entry for people down the line.

The decision then (imho) is between drupal and wordpress on the basis of community size, maturity and solution/problem fit. Processwire, however nice and cool, has an unproven record. Sure it is an interesting project but it lacks on number of contributers, governance model, etc; the very reasons that determine the longevity of a project. Just going through the git history one can see there is just one contributor. Should we choose a solution to go with at the very least it would need to withstand the bus test (http://www.urbandictionary.com/define.php?term=bus+test).

Between the two then, drupal wins hands down (imho). The reasons I believe so are elaborated in this post viewtopic.php?f=292&t=127645#p339754.

Having said that I think that choosing a CMS should be the least of out worries because there is still uncertainty on a number of issues that I expressed yesterday on the post that beluga kindly linked above.

[edit]
BTW another kudos to beluga for bringing OpenHatch to my attention, pretty cool stuff, thanks.

tassos wrote:BTW another kudos to beluga for bringing OpenHatch to my attention, pretty cool stuff, thanks.

Incidentally, Lydia & OpenHatch go way back (see also the sidebar of Lydia's blog).

About your claims regarding ProcessWire:
1) it is not unproven: the module directory has ~350 modules and PW's history that back to 2003. Not sure, what the criteria are for "proven", though.
2) you confuse the contributor stats, because there is only one person merging patches

In my analysis I had a hard time thinking up "Cons", so I included the bus factor problem, but I didn't seriously think it was a dealbreaker. The lead dev said in 2013 that there are at least 5 other persons capable of taking over, if he suddenly passed away (the number has obviously grown since then).

I find it strange that you first talk of the prevalence of PHP and then recommend projects that require a lot of learning overhead on top of PHP knowledge, including as a bonus lots of obsolete legacy PHP and bad coding practices (thinking of WP in particular). I understand the consensus is that for a PHP developer, learning Drupal takes an average of 6 months. Contrast this to PW, that adds so little on top of PHP that "last time I recruited the fellow I ended up hiring did build full pw website on the very same day we had an interview".

Choosing a CMS based on its existing community size is not some rule written in stone: LibreOffice uses SilverStripe for its main website and Plone for its extensions site. They are both in the same league as PW regarding popularity.

And that is why this experiment failed already when we tried it a couple of years back... more opinions, hard to achieve an agreement

Just as a side note, lets avoid being defensive about this discussion; if this was an easy decision we wouldn't need to talk about it. We're not picking winners and losers, we're just looking for the best fit among a list of capable systems.

On Django I've got to say that being non-PHP is too much of a dealbreaker, at least in my opinion. Technically speaking KDE.org is already PHP-driven, and we need a system that can easily integrate with other PHP components; using another language on what is ostensibly the 'glue' CMS is just a bad idea. I've known about the project for a long time and I've heard some pretty nice praise, but trying to integrate Django into a PHP ecosystem is setting it up for failure.

On PW vs Drupal, I think we can talk about them all day, but at this point we just need to codify our conditions for using one vs the other.

With Drupal it provides more than PW, but it also comes at what I'm seeing is a higher technical cost, complexity, and overhead. PW provides less but by all accounts it's just technically cleaner and 'closer' to PHP. So the choice boils down to either dealing with a more complex but complete system, or adding our own extra modules to a simpler system. I don't mind this as much as some, because it means we can tailor our solutions.

And even though it's unintuitive, I also really respect the fact that the ProcessWire guys have stated when it's best to use competing systems. It tells me that they grok what their system is designed to do, and that they aren't full of themselves or deluded into thinking their solution is perfect for everyone. It's a very healthy attitude I think, and good developers generally know what the limits of their systems are. I also like that even though there's a dedicated maintainer making the system great - there's people in the wings pushing up the bus factor. If the guy has to leave for any reason, at least we know maintenance will not falter.

There's also the fact that Drupal is in a strange transitional position moving from 7 to 8, and apparently has a 9 on the horizon; this bothers me because I want to build KDE.org on the latest software so we aren't outdated by the tiem we release the website. The 8.0/9.0 issue it tells me as a developer that either 8.0 is something transitional itself, is of low quality that they want to supersede quickly, or that they as a developer community are unfocused. Why work on 9 when 8 isn't even out yet? We weren't starting "Plasma 6.0" while 4 was the recommended system. Are we going to suddenly be 2 Drupal versions behind in 4 years? Are we literally going to build against the Windows XP of Drupal releases, well supported but equally outdated until age dictates they pull the plug?

So, here's my stance; I want to use ProcessWire, I'm sold on it as a system. My hands are on the chips and I'm ready to slide them onto the table. Drupals overhead and seemingly muddled version milestones is a serious turn-off for the goal of a viable long-term website. Drupal may have a much larger community, but soon it will be fractured between 3 releases.

BUT there's clearly some shortcomings which PW as a project must solve to push it past Drupal. I think we should list that issues we have with PW (which can reasonably be tackled), and see if we as a group can push PW into our comfort zone. If they can't be solved then we'll go with Drupal. I don't think we should list technical issues yet, at least not until development shows what's important, just project-level issues.

If this sounds fair, my own issue is the lack of a well-defined security policy. I think if we're to use PW we should speak with their developers and see if they can put a formal policy in place for the event of security issues, and also erect a security advisories page or feed which we can reference. KDE.org is big, and if there's a security issue we need to know we can quickly respond before hundreds or even thousands of pages are put at risk.

Outside of security, are there other considerations we should check into?

Kver wrote:Outside of security, are there other considerations we should check into?

I guess the issue of smooth migration between staging/dev and production. Wanze said he is interested in taking over this incomplete project: https://github.com/mindplay-dk/SystemMigrations Other PW devs will probably contribute. I can poke Wanze about his plans and schedule.

Perhaps it would now be good to focus on more detailed specs and building some frontend stuff (and agonizing over what frontend tools to use).
Then as the whole thing becomes more clear, time goes on and new CMS versions arrive, it will be easier to decide which is a better fit, D8 or PW3. There might very well be something lurking in the future that is a dealbreaker for PW

@kver
I think you are confused about the Drupal versions. A project natural progresses, and it has a plan on how long it will support releases. No one said anything about being working on D9. I just said that D7 will be officially supported until D9 gets out which will be at least another good 4 years before it happens, because that was how long it took to develop D8. So D7 is going to be supported with security and feature releases for quite some time.

The argument is much more than adding a few modules to PW or tailoring it to our needs. With customisation come maintenance, and maintenance needs constant expertise and resources. It is an added layer of complexity. If a large project is chosen a lot of the burden is shared, reusing functionality already written and maintened by
the project's community. After all the most important thing is to get a website to express the vision and a goals of KDE, not a website that would need constant fiddling and mending.

Still important are deployment tools and workflow and ability to integrate with CI. It is still unclear to me how PW measures up in these. I know wordpress is really lacking in this department.

@beluga proven means real world websites that can attest to the appropriateness of the system in question as a tool. For instance drupal has these use cases, among others:
- http://www.teslamotors.com,
- http://www.economist.com,
- https://austin2014.drupal.org/session/m ... ercom.html

A lot of high traffic, high profile websites prove that drupal is a solid platform that has been used by a lot of agencies around the world for problems similar to those we will need to solve for the kde website. Plone does not have similar use cases to show because people do not really consider it for projects such as these.

Any PHP developer worth their salt can figure out drupal API without a sweat. Heck I've seen front end guys producing deployable code in less than a month, albeit not good code.

tassos wrote:@kver
I think you are confused about the Drupal versions. A project natural progresses, and it has a plan on how long it will support releases. No one said anything about being working on D9. I just said that D7 will be officially supported until D9 gets out which will be at least another good 4 years before it happens, because that was how long it took to develop D8. So D7 is going to be supported with security and feature releases for quite some time.

That clears things up! I've seen some insane things in my development career, so my jaded perspective immediately assumed the worst. Glad to hear that Drupal isn't written by crazy people.

(sad thing is, I've seen worse)

tassos wrote:The argument is much more than adding a few modules to PW or tailoring it to our needs. With customisation come maintenance, and maintenance needs constant expertise and resources. It is an added layer of complexity. If a large project is chosen a lot of the burden is shared, reusing functionality already written and maintened by the project's community. After all the most important thing is to get a website to express the vision and a goals of KDE, not a website that would need constant fiddling and mending.

Still important are deployment tools and workflow and ability to integrate with CI. It is still unclear to me how PW measures up in these. I know wordpress is really lacking in this department.

@beluga proven means real world websites that can attest to the appropriateness of the system in question as a tool. For instance drupal has these use cases, among others:
- http://www.teslamotors.com,
- http://www.economist.com,
- https://austin2014.drupal.org/session/m ... ercom.html

A lot of high traffic, high profile websites prove that drupal is a solid platform that has been used by a lot of agencies around the world for problems similar to those we will need to solve for the kde website. Plone does not have similar use cases to show because people do not really consider it for projects such as these.

Any PHP developer worth their salt can figure out drupal API without a sweat. Heck I've seen front end guys producing deployable code in less than a month, albeit not good code.

I think your last point just killed Drupal for me; If your using "learned how to produce not-good code in under a month" as a point *for* Drupal, that's a red flag. If it takes half that time for a veteran programmer to hit the same level - that's still weeks spent learning a complex system. Even then we'll be deploying code without being experts, which no doubt will result in hacks and bad code. I've been reading and even if it only takes weeks for a good developer to start writing Drupal stuff, I'm seeing people say that it's still usually months before developers are able to write *good* code for Drupal. I don't have that sort of time, and I'm not going to tell others to invest that time for me.

By the looks of it, Drupal requires larger sustained time and effort to write for. ProcessWire requires higher initial effort to fill in some gaps, but will concequently be much leaner to develop on. I'd much rather take those two weeks I would have spent learning Drupal to write modules for a simpler system which adds the functionality we wanted; and in that case we can be good community members and start publishing modules.

I don't think having a system which integrates everything and-the-kitchen-sink is the ultimate goal; we'll be writing a large amount of custom code anyways. KDE.org has incredibly diverse needs, and we'll be purpose-writing that functionality, and as a barrier-to-entry I think one or two missing modules is acceptable compared to complicating every subsequent module we must write. This prompted me to do some real reading and I'm finding a lot of people who say Drupal is a pain, and that writing Drupal *properly* takes huge amounts of time and effort. It's also worth noting that ProcessWire is developed by people who have used Drupal, and they specifically wanted to avoid several Drupal pitfalls.

On lots of proven websites using Drupal, I like to see websites and how they use a system, but saying "lots of people use it, so it's good/proven" is a weak argument to me. Drupal is incumbent so it naturally has a much higher install base, it's like saying Wordpress is the best blogging platform because most blogs use it.

As it is right now if we can get the ProcessWire guys to put a security policy into place, I'll be satisfied enough to put my vote fully behind PW. Despite my earlier mistake on versioning, my real research of the two leaves me looking at Drupal as being cumbersome and overcomplicated in exchange for a few extra features. Reading the documentation on building modules between ProcessWire and Drupal, I also find myself preferring the ProcessWire API; it's using PHP to the hilt, where Drupal seems to be inventing file formats for things like configuration. Both projects are also well documented. Assuming they write a policy, my vote is to use ProcessWire, write the missing modules, publish them, and build from there.

@Tassos; Are there any ProcessWire concerns you have that might be able to fix by talking with the ProcessWire developers which might make you more comfortable?

I have explained my reasons and why I think PW should not be considered at all for our use case.

tassos wrote:I have explained my reasons and why I think PW should not be considered at all for our use case.

I highly encourage you not to shut down just because I'm currently preferring PW, and I know as a serious Drupal dev it's difficult to potentially help another project potentially compete against your preferred system; right now for this decision we need to take a methodological and unbiased approach to picking our technologies through frank and earnest discussion, and when several people are vested in different technologies there will be disagreements. We also have to remember that these discussions aren't meant to be personal, and as a dev to another dev I plead that you don't mentally check-out.

If you have points you want to distil in regards to ProcessWire as a technology or as a project, please list them. I know you've already given several points mostly in regards to Drupal as a more mature and larger community, but that's something only time can fix for ProcessWire. I agree with you on security policy, and I think that's something they can solve which will benefit them as a project, should they choose to implement it.

I haven't ruled out Drupal either. I'm polling you and everyone else for actionable issues seen in ProcessWire, if they can't or won't be solved to reasonable satisfaction then Drupal is back in the limelight. As an expert in Drupal you may have more angles for us to examine in PW - and I hope you can agree that even if you feel we're making a mistake, it's to everyone's benefit if you provide thoughtful feedback to make the best of the second-best decision.

...

In the effort to move things along, I think what I'll do is wait to see if anyone has any more points to bring the ProcessWire crew until this Friday (the 21st), unless anyone wants me to hold off for a bit; so if there are concerns we want to raise directly with ProcessWire before we start development with their system, please try to have them before tomorrow night / Friday morning. If they are willing to work with us on our points we'll move along with development on ProcessWire, and if they don't we'll proceed with Drupal.

Is this agreeable to everyone?

I am not shutting down, to the contrary, I just feel that I have said enough and do not want to push with my view more. I think the case for Drupal is done by neverendingo. I just provided some insights from the trenches.

I feel that my points were more than the community is bigger. My main concern is that we are treating this as if it is a software project when it clearly is not. Who gives a toss if a or b is easier to develop if it is very difficult for the editors. What is more important to have a stable platform fit for purpose proven now and again or a pet project of someone (not insinuating that PW is anyone's pet project, just making the distinction for arguments sake)?

Our aims should be:
- to write as little code as possible and minimise any subsequent investment of resources that may be needed down the line,
- provide a platform for content to strive that editors can use effectively,
- keep it as simple as possible.