Matthew Flatt wrote at 08/29/2013 03:14 PM:
In fact, we want to get rid of the notion that the packages that are currently in the main distribution are special --- at least, not in any way except that they happen to be selected to be in the distribution that PLT provides right now. That's why I keep putting "third-party" in quotes; all packages are considered "third-party" by the package system.
One distinction that I'm not sure was articulated, between pieces of DrRacket and what I'd call an ecology of reusable third-party components, is in the who/what/when/where/why/how of the components' lifecycles.
Few third-party developers have releasing Racket third-party packages as part of their job descriptions, and third-party contributions seems to largely be altruistic. As for altruism, I can attest that trying to promote Racket as a third-party R&D person for the last decade has not shown financial returns like simply riding the popularity of some other platform would've. And third-party packages aren't often part of a tenure bid, nor listed on many grant applications. When packages aren't coming from PLTers and random grad students (who might get academic career traction out of it, in addition to the altruistic and vision factors), I think packages are generally coming from hobbyists and maybe sometimes from businesses. In the case of businesses, they're often toying with the idea of giving back, perhaps for hiring PR, or indulging some valuable employee's interest in open source, if it's not too expensive to do so. The third-party motivation seems generally altruistic or fragile/fleeting.
In my particular evolving R&D vision for an ecology of reusable third-party components, and how that might happen without without encumbering the agility of third-party developers who decompose their apps to include reusable components that can be open-sourced almost incidentally (e.g., easy to release and update, backward-incompatible changes are OK), as well as making stable apps developed using large numbers of these components practical (e.g., managing and mixing versions, and a compatibility info/mechanism)... there are very different needs than DrRacket has had thus far. An initial cut at breaking the DrRacket code base into packages will not encounter and have to address many of these different needs.
A hypothetical exercise: If, after DrRacket has been broken into packages, all the PLT developers cease speaking with each other for a few yeas, and release changes to their respective pieces of DrRacket only as weekend hobbies, or by sneaking it past their employers, and they start building important things upon numerous other third-party components, and they start seeing surprise incompatibilities between components that breaks their important apps, and problems mixing apps and components with incompatible version dependencies... then, even though they had the freak advantage of a long-centralized starting point for their packages, then they might start to appreciate lifecycles like real third-party packages, and apps of same, will.
That's why I'll continue to say "third-party" without quotes around it, for now. :)
Neil V. ____________________ Racket Users list: http://lists.racket-lang.org/users
