I’ve been looking at the draft of this since April, 2015. I’m going to take Jorbin’s advice and just press publish so that it’s no longer a draft. Most of this observation is informed by my perceptions of structure inside the university when providing a central service. It’s still interesting.
We provide an excellent base service for groups inside the university. We build features to extend this base service. Most built features are available to everyone.
Groups paying us to extend the base service tend not to join the community discussion—or not frequently.
Groups without dedicated funding have participated regularly.
Both groups, for the most part, have their concerns and requests addressed. Groups with funding can demand timelines. Groups involved in the community are frequently vocal and pleasant.
Balancing the concerns of each leads to useful features for all.
The difficult group is the one without funding that does not join the community. Our base setup is easy, but prioritizing feature requests is near impossible when juggled alongside the previous two groups. This group quickly becomes an outlier for our workflow.
How do you convince that group to join the community?