This document discusses perspectives on release cycles for open source projects and how they may impact core development work. It notes that shorter release cycles could help align company incentives with core development. However, frequent releases may also introduce more noise and distractions that make tracking core work more difficult. A possible solution proposed is for core maintainers to focus on fewer things.

1. Eric Gundersen
user name: ericgundersen /10223)
project involvement: hand waver
/10223

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.