The standard advice on new opensource projects

The Linux Advice
Work on a project alone until the project becomes so big, successful and large that other developers beat a path to your door.

This isn’t really very useful advice. It kind of implies some extreme assumptions– no one will help on a small project, and only really big, successful one man projects can attract community contributions.

Code yard sales
I heard the phrase first on Hanselman. Here’s some junk code, have fun. Because the original commiter is so … uncommitted, the project isn’t likely to go far.

This model has it’s places, but it doesn’t help if you want a medium sized open source project to grow and have some modest success.

Face it, odds are low your project will become as successful as Linux and it’s unnecessarily lazy to give away your starting code base and abandon it.

WordPress-style Plug in Model
If the application is designed from the get-go for extensibility in a variety of ways, from basic stuff like using abstract classes and interfaces, to using a full blown plug-in architecture, then people can  contribute in an unco-ordinated fashion, perhaps without even committing to the main trunk.

The core of the application is a component host. The lead developer first job is to provide the glue for the parts. The particular functions would be secondary. I think this is counterintuitive, but essential. If I have an idea for a great blog engine, if I write a blog engine first, I will have to retrofit it for plugins. If I write an application host first, albeit one optimized for plugins, then it will be a very different application.

Validation Application Block Post Mortem

VAB seemed to work only for simple domain restrictions on a single property.  This is the least interesting, least value providing sort of validation.  At worst It is a 2 line if/then block of code! Replacing it with an attribute saves 1 line of code and creates some design rigidities.

If you had complex logic (and it didn’t have to be very complicated), one was tempted to write complex expressions in attributes. This is ugly programming.

If you had complex logic, you were supposed to write custom validators.  Contrary to this blog post, which says, “This is very easy to do”, this is not easier than writing a Validate() method– at the very least, it’s 100s of lines of extra code.

The custom validators tend to be a lot like
List<string> Validate(MyObject someObject),
which is the way things were before attribute driven programming.

The codebase began to evolve to use VAB less and less.

Today I’m removing the assembly.

Picking .NET tools when you want to collaborate

Something as simple as solution folders can stop you from collaborating with anyone except Visual Studio Professional.

Strategies for the IDE
Target the largest crowd.  For example, everyone with VS2005. A good percent of those people only have a licensed copy at where  work and won’t have time to dink around with an open source project, unless it happens to be solving a commercial problem for them.

Target multiple crowds.  Eg. distribute with #ifdef statements for 1.1,2.0,4.0, Mono and six different solution files and project files targeting VS.NET, VS2003, VS2005, VS2008, VS2010, and monodevelop. The extreme version of this strategy is crazy.

Target the poor. Visual Studio Express, Nant + notepad, csc.exe + notepad, WebMatrix, CodeRun, MonoDevelop. Ok, but some of these have really low productivity characteristics.

Hybrid strategies. Make sure the largest crowd can contribute and maybe one subset of the poor or different, such as the previous release of VS or Visual Studio Express.  This will require periodically opening the solution in the less expensive environment to make sure that you aren’t using a feature the other IDE doesn’t have.

Strategies for the rest
git hub or CodePlex or what? Use one site for bug tracker, source control and everything or pick your favorite bug tracker, source control, etc.

VS2010 Express + SVN/Git + Team City
You can create DLLs, WebForms, MVC, Silverlight widgets and WCF services. So it’s kind of like being in a ‘all-you-have-is-a-hammer’ situation, so these are your hammers.

VS without Ankh is a bit trickier, you’ll probably just use tortoise. You will need to know on your own to not check in /obj/  .cache, .suo, maybe not /bin/

Codeplex has an SVN bridge. Cool.

Since you can create DLLs, you can create unit tests separate from code-under-test.  At the moment, all I can find the nUnit GUI test runner. I’m not seeing a way to add commands to the menu in VSExpress, but you can add post-build steps that will call the nUnit GUI test runner. On the otherhand, you wouldn’t want that to run in the build server, because the build server would have it’s own unit test runner.  So again, it’s just a non-integrated experience.

SQL Compact and MS-Access

So I saw SQL Compact 4.0 was released and I was excited for a whole hour. A data source is as useful as the tools that can connect to it. Just about everything can connect to an MS-Access database or to a SQL Server database, via Oledb, ODBC,  MS-Access linked tables, you name it.  You can even get MS-Access to connect to an XML file or a HTML table.  But HTML isn’t a real file based database and MS-Access’s JET-SQL is just different enough from TSQL to be annoying. So it would be nice to be able to have MS-Access use SQL  Compact as a datasource, esp as a linked table and not as an ADO datasource in VBA scripts.

But as far as I can tell, this just isn’t possible to do *without writing code*. MS-Access used ODBC to talk to unfamiliar datasources and AFAIK, there isn’t an ODBC driver to SQL Compact.  Googling turned up MSDASQL, but that solves the converse problem of getting an Oledb consumer to talk to ODBC. And MS-Access is an ODBC consumer.

So that leaves either importing all my data from SQL Compact into MS-Access (not too exciting) or writing VBA code, which might enable some scenarios.  This is one possibility I haven’t completely explored- MS-Access can bind to ADO recordsets, maybe including SQL Compact. It’s a possibility.