I like it, although I think there are other organizing principles to explore. Seconded on all the 'fork' comments its not at all intuitive to a chef what you mean here.
At present the top level abstraction is the recipe which you've sort of equated to 'source code' but when you look at something like Github or Sourceforge the high level abstraction is the 'project' and in the food world the closest I could come up with is 'cuisine.'
Consider one of my daughters favorite sites: http://smittenkitchen.com/ this site has lots of interesting recipes, and one might use them as a top level abstraction. So you've got the 'smittenkitchen' project equivlent or maybe 'smittenkitchen-breakfast' project which is breakfasts from smitten kitchen.
Then there are chefs which are much more important in the cooking world than individual developers are in the programming world. That is because the chef's 'taste' really defines the product in a way that is fundamental to the enjoyment. So you might want to build a '<Chef>-<category>' type model. Then you could do a pull of <Ramsay>-<appetizer> and get various appetizers that Gordon Ramsay makes.
Of course that will get you into a licensing battle. Because like fonts, recipes have this weird quasi relationship to name vs instructions (can't copyright instructions, can copyright the name, google Font Copyright for more info)
Conceptually I think this is a really winner idea (sadly easy to copy) but if you get the right mix going and critical mass it could easily be as successful as github or sourceforge.
Hey, at Fork the Cookbook, we're doing just that right now! It's one of the primary reasons why we said Search is Hard [0]. And we're working hard on search.
We've also put a lot of time and effort into researching the licensing issues, as well as design issues: how to present certain things like diffs, and stuff. So if you like, you should check out Fork the Cookbook: http://forkthecookbook.com
Hey there, it's not a feature we've pushed out live yet. There is code to see diffs, but no on the public facing UI yet.
The reason is this: We don't want to aim at the tech crowd (which is why you haven't seen a Show HN from Fork the Cookbook). The tech crowd knows what diffs are. We're used to reading things that look like this:
But the public aren't used to reading stuff like this. What we're working on is a comprehensive way to explain what diffs are, and what it means. So we're back at square one, designing a representation that is human worthy.
At present the top level abstraction is the recipe which you've sort of equated to 'source code' but when you look at something like Github or Sourceforge the high level abstraction is the 'project' and in the food world the closest I could come up with is 'cuisine.'
Consider one of my daughters favorite sites: http://smittenkitchen.com/ this site has lots of interesting recipes, and one might use them as a top level abstraction. So you've got the 'smittenkitchen' project equivlent or maybe 'smittenkitchen-breakfast' project which is breakfasts from smitten kitchen.
Then there are chefs which are much more important in the cooking world than individual developers are in the programming world. That is because the chef's 'taste' really defines the product in a way that is fundamental to the enjoyment. So you might want to build a '<Chef>-<category>' type model. Then you could do a pull of <Ramsay>-<appetizer> and get various appetizers that Gordon Ramsay makes.
Of course that will get you into a licensing battle. Because like fonts, recipes have this weird quasi relationship to name vs instructions (can't copyright instructions, can copyright the name, google Font Copyright for more info)
Conceptually I think this is a really winner idea (sadly easy to copy) but if you get the right mix going and critical mass it could easily be as successful as github or sourceforge.