Elsewhere, the question was asked:
	  :	How can you do XP writing a framework?  Who is your OnSiteCustomer? How do you do the PlanningGame? Who are the GoalDonor and GoldOwner?  Who writes UserStories?

SoftwareFrameworks can easily slip into the realm of complexity and irrelevance (see: FrameworksConsideredHarmful).  Because of this, the importance of the ExtremeValues is magnified.  To curb complexity we are more aggressive in applying simplicity, and to curb irrelevance, we up the feedback and communication.

'''Simplicity''' might exist if we:
	* Evolve the framework from as much real use and as little speculation as possible.  RonJeffries said in http://groups.yahoo.com/group/extremeprogramming/message/19877:
	  :	''I'd address that concern, as a framework builder, by building applications, then finding the common "frameworky" elements that had been used, and extracting them to be the framework. I might extend the framework then speculatively, in ways that don't change its shape but add functions. For example, if the framework used sine and cosine, I'd add the other trig functions, and suchlike.''

	* Limit the scope of the framework, possibly splitting it into smaller, orthogonal frameworks.  On CriticalSuccessFactorsOfObjectOrientedFrameworks, KentBeck emphasizes the value of Simplicity:
	 :	''My critical success factor is that the whole framework, including test cases, must be able to be redeveloped from scratch on the train from Munich to Erfurt. The frameworks I come back to time and again have this quality. You learn more each time, and you learn more about what you can leave out.''

'''Feedback and Communication''' are maximized when a real user is involved.  Maybe we could:

	* Develop the framework for in-house developers.  RonJeffries's idea above seems to lean this direction.  Refactoring common code across projects into a common pool might bring elegance.

	* Hire an end-user as the OnSiteCustomer.  This has its challenges, but would probably solve the problem.

	* Accept test code from the end-users.  This one is a bit radical, but it might just work, and it might be necessary if your user base is large enough that it becomes difficult to get an accurate sampling on-site.  Envision this: Your users send in feature requests as failing tests.  The developers estimate these as they come in.  The product manager then prioritizes them and from this point ExtremeProgramming continues as usual.  The framework team could even publicize their test code to allow the users to leverage it where helpful, such as using its MockObject''''''s.  This scenario ensures that there is no mistaking what the user wants.

-----
[CategoryFramework]