2. Question: Could shorter release cycles help align
incentives in companies to do more core development
work?
Or reworded slightly: Could core development work
help our projects better succeeded thus has a
pragmatic appeal like contrib. does?
3. **Perspective 1**: (out pacing our projects)
Say we are doing lots of aggregation work.
-- Drupal 6.0 released - AKA Drupal 7 Starts _Feb ‘08_
-- FeedAPI 1.0 Released _Feb ‘08_
-- Suggesting a new aggregator for Drupal 7 _Jul ‘08_
-- Starting core 7 aggregator work _Aug ‘08_
-- StumbleSafely.com _Nov ‘08_
-- StumbleSafely.com _Nov ‘08_
-- Stopping Drupal 7 core aggregator work _July ‘09_
-- Managing News launches _Oct. ‘ 09_
-- Good bye FeedAPI, hello Feeds! _Nov. ‘ 09_
-- www.afghanistanelectiondata.org/data _Dec ‘09_
-- PubSubHubbub Support for Drupal _late Feb. ‘ 10_
-- Managing News Beta 9 Released _April ‘ 10_
4. **Perspective 2**: (so much noise)
_Issue_: Trying to track work happening in core
takes more time than contrib because so much else is
moving that you need to watch that is tightly
associated with the work you are doing and
distracting.
_Possible solution_: being more selective of what
core maintainers should focus on. aka focus on less.
5. Notes:
This is just from the perspective of a small
business looking at team resources (as notes, this
is coming from a hand waver, not a developer). To be
clear, this is not about trying to justify time for
open source altruistic work. We do open source work
because it makes better product.