Question: I have a UITableView that displays various nsstrings from a custom object called a "Transaction." in CellForRowAtIndexPath it the allocates a new instance of a transaction and then copies the the values from a particular transaction that lives in the delegate array so I can access it from different views. It then uses the new transaction 'copy' and it's properties to popluate the table cell. The problem I'm having is if I release the copied transaction object when I go to redisplay the table the app crashes. if I comment out the release the program runs well, but I'm worried about memory management obviously. My question is what the heck should I do, is there another place to release this?

Here is the code:

```
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {

static NSString *CellIdentifier = @"TransCell";

UITableViewCell *cell  =  [tableView dequeueReusableCellWithIdentifier:CellIdentifier];
if (cell == nil) {
    cell = [[[UITableViewCell alloc] initWithStyle:UITableViewCellStyleDefault reuseIdentifier:CellIdentifier] autorelease];
}

// Set up the cell...
NSUInteger row = [indexPath row];
CashAppDelegate *mainDelegate = [(CashAppDelegate *) [UIApplication sharedApplication] delegate];

Transaction *cellTrans = [[Transaction alloc] init];

cellTrans = [mainDelegate.transactionArray objectAtIndex:row];

NSString *string = [NSString stringWithFormat:@"$%1.2f %@ | %@", cellTrans.amount, cellTrans.category, cellTrans.descriptionString];
cell.accessoryType = UITableViewCellAccessoryDisclosureIndicator;

cell.text = string;
//[cellTrans release];
return cell;
}

```

Answer: 
I find that motivation in the open source world generally comes from scratching an itch. I'm motivated to work with a project if I use it regularly, if it does something particularly useful for me, if there's a shortcoming I can see my way to fix.

The hard part is finding not just like-minded talented people, but specifically those for whom it scratches a similar itch: I think those are really your target "market" of people who might join in. In the commercial world, we employ sales and marketing people to go out and persuade people that our software scratches their itch, but we don't usually expect to find people to work with us. In the free world, the measure of credibility is different and I don't know of any better way than what you're already doing:

* Exist
* Be of quality (*waves hands* - whatever that really means from a fellow geek's point of view)
* Build up a user base (which is a double-edged sword, as you've found, with regard to bug reports)
* Make sure you're googleable so that somebody with the same itch and enough nous to search will find you rather than reinvent the wheel for themselves.
A few things you can do:

* clarify your role within each project. Just because you open sourced the code does not mean you opened your schedule.
* lower the barrier for contributors i.e make sure
	+ you have a clear roadmap listing the major milestones. What has been accomplished and what needs to be done.
	+ review your HOWTO guides for contributors
	+ clear instructions on how to install and develop locally
	+ review and simplify your codebase
	+ pick technologies that are more likely to attract contributors
	+ have small tasks identified either in the code or the site that anyone can take
* be very responsive to discussions about patches and encourage them
* get to know your users (the ones who log issues). Maybe you are not targeting enough users with the right skills to make changes?
* raise awareness of the work being done and the stuff being requested e.g Here are out top issues, or most viewed bugs or most commented discussions.
* code patches are not the only type of contribution. Identify other roles in the project e.g bugs triage, marketing, packaging, testing new releases, forums etc. and again lower the barrier
* continue your efforts in attracting more users. Contributors will be a small percentage of that user base

	+ start measuring the installs, usage, traffic etc.
	+ add a website and make sure your install, configuration, requirements etc. are well documented and actually work on all supported platforms
* focus on users who provide feedback and have skills. They are the most valuable resource.

It all depends on what you want and how you envision your projects. 

Also, review the language and tone. People can sense if you are aiming small or big.

Finally check the alternatives and related projects. What are they doing right? or are they struggling in this area too?

Two excellent books to check out:

* [The art of community](http://shop.oreilly.com/product/9780596157234.do)
* [Producing oss](http://producingoss.com/)