Point of divergence from Drupal 8 and technical goals

[tedbow]

It seems like Backdrop split from Drupal starting here:

http://drupalcode.org/project/drupal.git/commit/d1aee00aaf7623616f791af8b64e14f39d74e372

Is that right?

Are there technical goals for this project as the major reasons for forking from Drupal? From looking at the commits and from looking at quicksketch's comments on drupal.org one could guess but it might be nice to get some details/discussion to help out those who are interested in helping with the project or are just interested.

So it seems removing Symfony would a big one.

Other goals? Is there discussion on this somewhere else?

[davereid]

@quicksketch is working on a post to get this information out as soon as he can.

[tedbow]

Ok, thanks for the info.

[quicksketch]

Hi @tedbow, yeah the "manifesto" is already written but before this becomes "official" (like it's not already), we want to make sure I communicate with all the stakeholders of Drupal that we can (core and contrib maintainers alike).

[tedbow]

@quicksketch thanks for the update. I (and I am sure many, many others) will be interested to see what the "manifesto" says.

[rudiedirkx]

Very interested. Will be published where?

[rudiedirkx]

The manifesto, I guess: http://backdropcms.org/

[RobLoach]

https://github.com/backdrop/backdrop/commits/1.x?page=2

Looks like it's Drupal 8 as it was in March 2012, with a couple downstream merges, and then new PRs.

[quicksketch]

@RobLoach see https://github.com/backdrop/backdrop-issues/issues/1 for the exact process.

[RobLoach]

@quicksketch Ah, very cool. Will check it out.

[quicksketch]

Hi guys, great discussion here and I can see that we need more clarity in the goals and structure. We've only been on this (hands-on) for a month, so we're still fleshing out everything as best we can.

The original document at http://backdropcms.org/ caused a bit of a stir around the negativity of Drupal 8. Obviously if we were thrilled with Drupal 8, this project wouldn't exist. But we're not trying to damage Drupal or the community, so the original document which contained a lot of the "why not Drupal 8" has been removed to prevent any further offense.

We're going to work on fleshing it out more in terms of actual goals, but I'll summarize here. First two are "in order", others, not so much.

1. Drupal 8 level features (CMI, Views, Editorial experience, WYSIWYG, etc.) while on the traditional (non-Symfony) architecture. This is our primary goal for the 1.0 release of Backdrop.
2. A permanent, slower-moving API, similar to WordPress but not as extreme, to ease the process of upgrading between major versions. An easier upgrade path for existing Drupal 7 users to Backdrop is our second most important goal.
3. More regular (minor) release cycles to deliver features at a regular interval, rather than 3 year jumps, without API breakage.
4. A focus on direct implementation and speed, rather than edge-case abstraction. For example DBTNG includes the ability to run MSSQL and Oracle, but those installs make up less than 1% of Drupal installs. That's unnecessary abstraction at the cost of performance, simplicity, and learn-ability.
5. An easy-to-understand architecture. You should be able to understand the basic premises of the Backdrop architecture (info files, hooks, and callbacks) in an hour.
6. New end-user features. Drupal 8 makes great strides in end-user functionality, but it fell short in several areas we'd hoped for. Notably a layout manager failed to materialize, which if there's one major functionality we hope to implement, it's that. Editorial experience still needs to be improved further, which I expect D8 will continue to make strides in, which we should at least match, but hopefully exceed.
7. Growing the community. Backdrop aims to attract new developers at all points of the spectrum, but especially remembering the entry-level developer. We want to be approachable and learn-able.

I hope that clarifies some things. We're already working on clarifying it in the manifesto.

One thing I don't want to introduce is a fear or aversion to OO code. OO makes a lot of sense in many situations, and I think it's inevitable that we'll use a lot of it in Backdrop 1.0 (i.e. the plugins architecture and Views implementation). We're not anti-OO, we're anti-complexity.

[patcon]

@quicksketch

A permanent, slower-moving API, similar to WordPress but not as extreme, to ease the process of upgrading between major versions.

Please please don't enshrine this in the mission. Major version bumps become associated with pain exactly because an API is slow-moving. In fact, a major benefit of semantic versioning is that it destigmatizes major version bumps, transforming then from cultural milestones into matter-of-fact technical milestones. Small, frequent API breakages are important -- we just need to start separately versioning each component/module and their APIs to make this sensible for Drupal/Backdrop. Thankfully, Composer makes managing this simple, and building releases centrally means the end-users are none-the-wiser of the componentization. (Travis CI with secure env vars powering the GitHub Releases API can make this easy breezy, with zero infrastructure commitments.)

This is all part of the agile and continuous delivery tenet of aiming for smaller and smaller batch sizes to deal with pain, rather than delaying that pain (which admittedly feels intuitive).

http://www.informit.com/articles/article.aspx?p=1833567&seqNum=3

[jenlampton]

Thanks @patcon, super valuable feedback. I've posted the goals up on http://backdropcms.org, but changed the title for that tenet to "Keep APIs Stable" to reduce the focus on the fact that it won't change much, and increase the focus on the goal: that upgrades will be easier. Hopefully this will allow us the flexibility to do what's needed while focusing on the goal, not the API itself.

[WorldFallz]

"For example DBTNG includes the ability to run MSSQL and Oracle, but those installs make up less than 1% of Drupal installs."

One major question-- does that mean backdrop won't run on MSSQL (or other non mysql/postgres dbs)?

Though I'm definitely not in an 'enterprise' environment with enterprise level funding, and imo fit squarely into the targeted audience of backdrop, I am absolutely and non-negotiablely handcuffed to a full MS stack (Windows/IIS/MSSQL).

[quicksketch]

One major question-- does that mean backdrop won't run on MSSQL (or other non mysql/postgres dbs)?

My understanding is that right now even Drupal doesn't run in practical usage on anything other than MySQL or Postgres because modules are actively discouraged from using db_select() for performance reasons. So most modules use db_query() which effectively means there isn't any query abstraction on most queries to begin with.

The primary concern here is around performance and learnability. If we can make 99% of Backdrop sites 10% faster (not a proven/real number) by removing MSSQL support, that majority will probably win.

[WorldFallz]

Obviously I can't speak for any of the other 6k+ users of sqlsrv (and I know that's a comparatively tiny amount), but I can attest that it definitely does work. I have a handful of sites using it with various combinations of the top 100 or so contribs and only ran into a few mssql specific bugs since d7 was released.

In any case, I totally sympathize with the reasoning, but am disappointed my d8 off ramp search may yet have to continue. :-(

[oadaeh]

@WorldFallz maybe you could chime in on the related issue: https://github.com/backdrop/backdrop-issues/issues/61

[jenlampton]

Doing some issue queue cleanup. Please reopen if there's more that needs to be added here.