Drupal Association members fund grants that make connections all over the world.
Drush make in the world of real profile development requires an understanding of a couple of basic concepts. The first concept is to understand that you have an essential need for no less than 2 make files. The "stub" make file, and your profile's make file. These together allow easy creation and distribution of light weight essential building blocks for your profile.
For more, see also: Managing Drush make files for an installation profile.
The Stub Make File:
The "stub" make file is a very simple construct. It references exactly two things. First it references the core version of Drupal you intend on using, and second it references the profile you intend on bundling with your distribution. There's an easy win here as well if you intend on bundling multiple profiles with your distribution. A perfect example of this could be an aegir platform.
Example stub make file
; make file for drupalorg_testing profile core = 6.x projects = drupal api = 2 ; Profile. projects[drupalorg_testing][download][type] = "git" projects[drupalorg_testing][download][module] = "drupalorg_testing" projects[drupalorg_testing][download][branch] = "master"
By way of make files, this is fairly simplistic. Again just referencing the version of drupal core we want, telling it to then GET CORE, and specifying the install profile to use. The install profile has further make files and will be recursively made for us, so we needn't specify any additional modules etc. The profile should take care of all of those things for us. In a perfect world, these stub make files can be stored, referenced, whatever and need not ever actually be updated until you're changing versions of drupal core.
The Profile Make File
As mentioned above, the profile(s) you're specifying in the stub make file should have its own make file specific to it. This make file is generally going to specify the additional modules you need, any directory structure beyond the default that you desire, any themes you may need and finally patches to modules. Typically we anticipate that a profile's make file will actually receive quite a bit of updating in the long term. This is because the best practice is to specify specific version of modules you wish to use. This makes it easier to maintain patched code, test new versions, and push new distributions only after testing has properly been done, instead of simply expecting all new versions of all code to simply work together.
For a good example of a profile make file check out open atrium's make file:
OA's profile make file is a great example as it pulls data from git, directly from drupal modules, applies patches, and re-organizes the basic directory structure of the modules it's downloading, placing contrib items together, custom features together, etc. Many of the best practices and coolest tricks can be seen executed in this file.
Keeping it all together:
For myself, I typically build a distro.make file locally with our stub make file in it, and then simply run drush make, but the question becomes, "Where do I store that distro.make file?" and there are a couple of potential answers. If you choose to store it along side your profile, that's perfectly fine, drush make will just end up doing a little extra work retrieving items it's already retrieved once. As a perfectionist, I prefer to keep a README.txt file with my profile that contains the stub make file's contents and describes how to use them. This is ultimately developer's choice, but putting the stub make file in the repository with the profile often confuses the uninitiated, and leads them to believe they should download the profile before drush making anything. This is fundamentally incorrect as outlined above. The stub make file can be made from anywhere, and it will generate a full Drupal install.
Working with drupal.org's automatic packaging:
I won't cover this topic in detail except to say that d.o essentially builds a stub make file for you on the fly when it generates a new release for your profile/distribution. You can read more on how to work with drupal.org's packaging here: http://drupal.org/node/642116