Do not answer the questions here (yet). Where and how to answer the questions is part of what we need to discuss. (yuck! ;)

The following list is based on initial conclusions and @chx's blog post.

Since then, discussion moved on and analyzed more in-depth issues in:

Especially @eaton's, @catch's, @Crell's, @EclipseGc's, and @sun's follow-ups need some attention - we need to check whether they contain additional discussion items, or whether one of the below needs to be adjusted and re-phrased.

Discussion items

We need to discuss...

  1. What we are able and want to maintain in Drupal core?
    (needs to cover all stuff that core provides, not just platform vs. product vs. framework; i.e., also subsystems, APIs, etc)
  2. Which core features are actually product features?
  3. A deadline for finding maintainers for product features?
  4. What we are going to do with stuff that no one wants to maintain?
  5. Whether we can or want to move product features into a separate product project?

    ...having the sub-topics:

    1. Whether product modules are going to be separate projects or contained in the same repo as the installation profile.
    2. Who is going to maintain the installation profile and/or product feature modules.
    3. How the "core" development workflow would look like, what changes are involved, and whether those are for the better or worse.
    4. Whether this change is going to be harmful in the long-run due to core developer "fragmentation" and separation (who would be kinda "split" into framework and product contributors) and how that affects Drupal's future.
    5. Which organizational/technical challenges exist for "core contributors" (since the identical people that maintain the product feature modules now would probably have to maintain them further in the short-term).

Procedure

Lastly, we also need to discuss where and how to discuss these discussion items.

@sun suggested:

Originally, I thought of everyone just simply copypasting those discussion topics, and publishing their input, opinions, and arguments on each item, on their very own blogs. That is, because these perspectives are not going to be directly actionable, but instead, they are independent answers to pretty tough questions. I'd still be in favor of doing that (and perhaps revising/completing the list of questions/discussion topics first, not sure whether it's complete). The only downside I'm able to see is that those opinions can't be "tracked" easily, and also can't be "merged" back into a d.o issue easily due to the fragmentation/distribution. But even with those constraints, the independent answers (not +1s) would be far more interesting and appealing to me. Lastly, I think everyone knows - publishing something on your own blog instead of some random issue on a community site makes you think twice about what exactly you write and propose ;)

Comments

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Issue summary: View changes

Updated issue summary.

catch’s picture

1. Acquia is being discussed here: http://groups.drupal.org/node/170999

2. "how we can resolve the lack of communication [about decrease of trust, burn-out, etc] without sacrificing our contributors and putting them into a dark corner at the same time?"

Yes this needs calm, rational, open discussion - although it is proving hard to balance the latter with the former (although I also wasn't at DrupalCon but I got the impression there was some fallout). I think that needs to happen in public, and while I personally don't care at all about how it might look to casual planet readers, I do care that people who care about that stuff don't get burned out...

3. These needs to cover all stuff that core provides, not just platform vs. product vs. framework.

4-7 are all fine. Although #7 is really, really, really far off being possible to do in any kind of useful way, and it is the kind of discussion that people get fixated on from both sides, so I would be tempted to postpone that discussion if possible, and focus on the short to medium term issues that are complete pre-requisites.

For the very, very meta discussions like burnout, I would recommend we use the core-improvements group on groups.drupal.org for now, and announce discussions via the core group. I'd like to see discussions like 'make core maintainable' kept in the core queue since they are the sort of discussions that tend to go extremely poorly on groups due to threading.

and possibly bringing in individual cases of burnout like http://drupal.org/node/76824#comment-3912648 (that issue has a long and IMO quite ugly history in terms of core process), as well as

webkenny’s picture

Forgetting who I work for, just for a moment, doesn't it make more sense for the health of an open source project to focus on a slightly different variation of #1? Something akin to:

How can we as a community ensure commercial entities don't predominately drive the project roadmap? e.g. Acquia, Lullabot, etc.

That seems like a better question to ask. With all the hoopla this week surrounding Acquia, we might be looking too narrow at a problem that could be much wider someday and we'd have wanted to plan for it. Consider this. You work in Drupal because you truly enjoy it, you work on core because you get it; once you do it's only a matter of time before a large entity wants to hire you or you want to work for a large entity. Let's not pretend there aren't some fiscal/career drivers for the work we do as developers. That would be naive.

As a community member (from core developer to forum angel who helps folks out), it seems there is a social responsibility to your project to ensure that when you go to work for these entities that you make it clear how community contribution needs to stay a part of your job. Developing the messaging around how one would deliver that during negotiation would be a valuable piece for people IMO.

It would also be the company's responsibility to understand that the community contribution is a healthy piece of any of their workforce. They can understand it or they can't. But if we hold true to our "code" not to work for companies who don't; you'll see how quickly the wells dry up. Ultimately we hold the power, folks. :)

If you need proof that model is possible you only need look at the Linux project. #1 Contributor? Red Hat. Others? IBM, etc. (Thanks @jacobsingh for that info)

I'm purposely staying clear of the other items since I don't work in core closely enough to have a strong opinion but I can tell you firsthand working for Acquia that the #1 driving concern expressed to us by executive leadership is the health and acceptance of Drupal. So I truly believe if a real plan was suggested for companies to follow and adapt to, it would be heard.

Anyway, thought I'd throw that out there as my suggestion seems to have more longstanding appeal than "Who is the company this cycle who is the offender?" - I am sure we will come roundtrip to others in the future as Drupal grows. Let's plan and be ready for it.

[EDIT: Landed this over on the groups link. I think this was the right place for it since we're talking text of question, but worth showing in both places]

sun’s picture

Issue tags: -Framework Initiative

Note: Started to write this follow-up early, will reply to to others later.

Regarding:

5. a deadline for finding maintainers for product features?
6. what we are going to do with stuff that no one wants to maintain?

Many of us ditched this idea already, and replaced it with the idea of not removing, but moving all product feature modules and creating a separate "default Drupal product" installation profile project - since that would solve most issues at hand.

In other words: Many core modules would be moved into contrib, but then re-referenced by the core install profile and pulled in by the packaging scripts.

That, however, would open a new can of questions:

  1. We need to discuss whether we want to move product development into a separate product development project, and how we feel about it.
  2. We need to discuss whether product modules are going to be separate projects or contained in the same repo as the installation profile.
  3. We need to discuss who is going to maintain the installation profile and/or product feature modules.
  4. We need to discuss how the "core" development workflow would look like, what changes are involved, and whether those are for the better or worse.
  5. We need to discuss whether this change is going to be harmful in the long-run due to core developer "fragmentation" and separation (who would be kinda "split" into framework and product contributors) and how that affects Drupal's future.
  6. We need to discuss which organizational/technical challenges exist for "core contributors" (since the identical people that maintain the product feature modules now would probably have to maintain them further in the short-term).

Again, these questions are not to be answered yet. Instead, we need to check whether's viable to ask them in the first place (I personally think it is), and whether questions about details are missing or need to be phrased differently.

sun’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

Based on #1 and #2, do we perhaps want to remove the discussion items 1. and 2. about acquia's influence and lack of (personal) communication? In theory, they're vastly different issues (even though I think they are crucial to ask with regard to the "core/product" discussion items).

@webkenny's suggested discussion item is, I think, a slightly different one. Primarily because no other Drupal shop has the same level of possible influence right now. However, it might be "easier" to move those items out of this discussion.

I've clarified 3. as @catch suggested, because yes, a full run-down on all in core is what I had in mind, too. Not just product features.

catch’s picture

@webkenny - I think there is an overall issue of the relative employment of core contributors and how this is divided between particular companies, and what kind of companies they are - Acquia (in its own category since it currently employs every active core committer which is why I think many people give it a special place, even if it is not actually that big in the scheme of everything else), niche service Drupal shops, full service Drupal shops, large 'site-owners' like Sony, freelancers, hobbyists.

Then there's an issue of how this does or doesn't impact core development. And beyond that there's an issue of the extent to which core contributions (and same goes for important contrib modules etc.) are an embedded part of their day-to-day work or have to be done out of hours for no money on top of demanding day jobs. These are somewhat contradictory (no funding == no influence, but no funding also means much easier to burn people out or drag them away from contributable work). I think this discussion is more for effulgentsia' groups post though (maybe with a new title).

SeanBannister’s picture

sub

plach’s picture

webkenny’s picture

I am complete agreement that the employment of core contributors relative to a company is important. I also understand why Acquia is a focus of that. I am more broadening scope because, although I'd like to think so, Acquia won't be around forever and the landscape rapidly changes for startups. Good points though, @catch and @sun. Definitely worth spinning off probably two topics. Core contributors time and company influence and how one relates to the other in the context of a single company (Acquia, and whatever follows) and the context of the industry as a whole.

webkenny’s picture

Issue summary: View changes

Updated issue summary.

sun’s picture

I've removed the first two discussion items, and merged the sub-topics from #3.

jherencia’s picture

jide’s picture

Following all these "Drupal crisis" discussions.

jide’s picture

Issue summary: View changes

Updated issue summary.