Paul Dix Explains Nothing

Great Law Blog for NY Entrepreneurs

I found this site in the sig of Imke Ratschko, one of the members of NextNY. It's her blog focused on small business law in New York. I've read through some of the posts and it looks like a great resource for NYC entrepreneurs.

technorati tags:nyc, law, entrepreneurship, small+business

HelpSpot 1.0 Released

Ian Landsman announced the official 1.0 release of his help desk software, HelpSpot, today.  Congrats Ian!  You're an inspiration to every aspiring mISV/entrepreneur.

technorati tags:  helpspot

Give me time!

Not a single post last week! I've been so pressed for time and it doesn't look like it's going to let up soon. I want to work on the product prototype, but have been completely unable to do so for the last two weeks because of time constraints. I'm getting bummed because this idea won't even get off the ground unless I can find some time to execute. Does anyone know how to fit another 8 hours into the day without resorting to serious sleep deprivation and copious amounts of coffee? How do other microISVs handle this? How do you set aside time to work on your product?

The Product Idea Continued...

Another buzzword has invaded my thinking with regards to The Product Idea and its name is Tagging.  Let me give you the background story...
One of the reasons I want to design this CMS for the common man is that I'm in dire need of this product myself.  When I think of content, I don't just think of web content.  I think of everything I create, receive and download on a day to day basis.  Email, tasks, class notes, meeting notes, blog posts, contacts, forum posts, web sites I like, music in my collection, ebooks, appointments, install programs, source code and other things I can't think of at the moment.  I'm talking about most everything I have digitally that I'll want to reference and/or share out at some later point.  When I add all that up, I'm producing, receiving, and sharing out an enormous amount of content week to week.  This is the problem I was thinking about that lead up to this idea.
I normally organize things within each program.  For files I just use the standard hierarchical folder structure as best I can.  For email I can arrange them in a hierarchical folder structure and by conversation (along with various sorting options).  On my web site the pages just go up based on the category I assign to the post and what month and year it was published.  If I want to go back and find something later I'm stuck with either remembering what folder I placed something in or the search utility in the program or on Google.  The search option seems to work great but it doesn't scale well after you have a large amount of content to search through.  You just get too many hits.  My idea to make this all better for myself is tagging.  Tag absolutely everything I put into the CMS.
I expect that right about now I'll get flamed by everyone for using the latest buzzword.  KC (of Casey Software) briefly mentions the phrase as part of the latest hot VC jargon.  Well despite it being one of the latest Web 2.0 catch phrases, I think the technology has great use.  The only thing is, it's been around for years.  Anyone remember the metadata craze of the late 90's?  Tagging is just metadata in a sexier dress.  Well metadata seems to have failed miserably (I'm not counting ID3 tags and program metadata that are embedded as part of the file structure).  How can I avoid the same failure in this product?

• Make it insanely easy to tag things.
• Tag things automatically based on where they get uploaded or created.
• Make finding content through tags easy.
• Let people stick with the old hierarchical model if they want.
• Integrate with other services.
• Keep the data open (no vendor lock-in).

I like the whole hierarchical model.  It gives you the option of having a specifically defined path to get to or find something.  Search just doesn't have the same capability when you're dealing with an ever expanding data set.  The only problem I have with the hierarchical model is that it's a little inflexible.  Search is all about flex and being dynamic.  I think we can bridge the gap with tagging.  The product can just dynamically build a hierarchical folder structure based on tags.  Thus you get the advantage of a fixed hierarchical model but the flexibility to place the same item in other places of the hierarchy when it makes sense.  You can also use tags to create a more informed deterministic search.
I'm sure there's more to this, but I just wanted to get a few things down.  I think tagging is going to be an integral part of this product.  Am I going buzzword crazy or am I on to something here?

Technology Selection: Ruby on Rails

Last week I promised a decision on technology selection for my wannabe ISV by end-of-day today.  Well the time has come and I have to make a decision.  In a perfect world I'd have more time to do research and play with things but it's time to get a move on and start slinging some code.  After much deliberation I've decided to go with Ruby on Rails.  The two main contenders were really just dotNet or RoR.  There were plenty of reasons to go with either one, but in the end it came down to a few things.
I've been playing with Rails for the last week and working my way through Agile Web Development with Rails.  So far I'm very impressed.  Rails seems uniquely focused on the type of application that I want to deliver.  The other reason is not technical at all, but cultural.  I love the culture that surrounds Rails and it's just the kind of thing I want to be involved with.  In the movie "Tucker: The Man and His Dream" Martin Landau has a line that goes something like "Never get too close to anyone. You'll catch their dreams".  Well it seems that passion, like a dream, is quite contagious.  I'm catching the passion that the RoR crowd has and it's part of the reason I'm going with Rails for this venture.
The Style Czar is psyched while The Adept is wary about having to pick up a new language.  Only time will tell how this decision works out, but for the moment I'm happy to have this decision out of the way so we can focus on learning Rails and how to build out The Product Idea with it.

Sometimes You Have to Fire Yourself

I fired myself today.  Well, that's not a completely accurate statement.  Let me give you a little background.  Earlier this year Christopher Hawkins wrote a somewhat controversial post about the 11 Clients You Need To Fire Right Now.  Along those lines, I turned down a freelance project today.
Was it because the client fell into one of those 11 categories?  Nope.  The client is completely reasonable with a project that has no reason to fail.  I turned it down because I wasn't comfortable about whether or not I'd be able to deliver to the client's needs.  Like many programmers I often get into the position of overextending myself.  Not this time.
This time I decided not to over-promise.
This time I decided to be realistic.
This time I realized that I have enough on my plate.
This time I realized that taking on another project may cause me to shortchange all of them.
So in a sense I fired myself from this project.  The good news is that the client appreciated my honesty up front instead of having it blow up halfway through.  It was a tough decision to turn down work, but I'm sure it was the right one.

I love microISVs

Ian Landsman just released the beta of HelpSpot.  It's always inspiring for me to see microISVs shipping software!  Congrats Ian!

Technology Selection: An Open RFC

I was going to wait a little while before talking more about technology selection, but then I realized that I could include everyone in the process.  In case you're not up to speed you should read about The Product Idea and some of our thinking about what technology to use in Technology Selection: Sharepoint?  Anyway, on to business.
I'm plodding forward with my research on what technology makes the most sense for us to use.  I'm doing most of the primary research with feedback from The Style Czar and The Adept (info on the characters in Introducing the Players).  At the moment there are a number of options under consideration (in no particular order):

1. Develop the system in C#.NET
2. Develop the system in Ruby on Rails
3. Grab an open source CMS and modify it to suit our needs
4. Develop a client heavy system which uses javascript/xslt (still in browser) and whatever web services framework is most convenient to serve up the data.
5. Other options?

Before I get into a little analysis of pros and cons, let me give you the bias of the team members.
The Style Czar heavily favors the use of Rails.  He's used some of the open source CMSes and is convinced that it will be a terrible pain to modify them to our needs.  He also wants to avoid .NET since he generally likes to stick with open source.
The Adept heavily favors the use of C#.NET.  He works with it professionally so any work done here will enhance his working resume.  Without the need to learn another language and web framework he'll be saved valuable time.
I'm leaning towards the Rails approach.  I really like what I'm seeing so far and it seems ideally suited to bring our project to life.  Also, I'd love to start working professionally with a new language.
Now I'll try to outline the pros and cons of each approach in a little more detail.  Please feel free to add your pros, cons and comments for each one.
Develop in C#.NET
Pros:

• no learning curve for The Adept and I.
• fully featured development tools.
• extensive development community with plenty of support and articles.
• continued development of .NET resumes for The Adept and I.  Not really business related but it is part of our considerations.

Cons:

• compiled code base.  You'll remember that one of our requirements was quick and constant updates.  I have concerns about redeploying the entire compiled app for every update.  Scripting language options don't seem to have this weakness as we can update each individual piece without affecting the deployment of the whole.
• expensive development tools
• server licensing costs
• I'm not sure how easy it will be for The Style Czar to make visual changes post deployment.  This one I'd like to get some feedback on.  If you're developing web applications for .NET, how easy has it been for your designers to change the visual things?  For me this process seems fairly static, with the designers creating a look and feel up front and the application developers conforming to that.  Then a final run through after it's functionally complete.  This just doesn't seem to fit with our whole idea of agility.

Develop in Ruby on Rails
Pros:

• Designed to create systems similar to this.
• No development licensing costs (unless we go with ArachnoRuby and even then it's cheap).
• No server licensing costs.
• Rails seems very up to date with Prototype and script.aculo.us integration.  This will help us with the whole web 2.0/AJAXification of our system.  Note:  I know they can be used independently of Rails, but there seems to be more traction here.
• Chance to get in with a new and exciting development community.  This one is just mine and not really business related, but for me it's a real pro!

Cons:

• lack of sophisticated development tools.  I can't seem to find the IDE, debugger options that make things easy.
• new language and framework for the team to learn.
• There seems to be development work going on already in the arena of Rails based CMSes.  Jason Fried mentions an upcoming release in this interview.  The Rails site even has a wiki about the subject.  This may not be an issue since we don't plan on developing this as a shrink wrapped app.  At the same time, I'd think that 37Signals would plan to release the thing as a managed app since that has been their business model (since switching to being an ISV) so far.

Modify Open Source CMS
We've basically ruled out the option of modifying an existing OSS CMS. We feel that if we're actually going to create a fairly new user-centric CMS, it should be from scratch.  There's too much danger of inheriting all the flaws that we think exist in the current crop of applications.  Another issue is that most of them are in Pearl, PHP, or Python; none of which are very familiar to our team.  There's also a fun factor of getting to architect the system ourselves.
Develop Client Heavy System
We've also ruled this option out.  It seems overly complex and could have way too many problems.  While whatever option we go with will include a decent amount of client side javascript we won't rely on that entirely for page rendering.

That's the basic run down as it stands right now.  Were we too quick to rule out two of those options?  Are there other options we should be considering instead?  Are we taking too much time thinking about what to develop this in?
Whatever the answers to those questions, a decision will be made no later than a week from end-of-day today.

Technology Selection: Sharepoint?

The first step in trying to bring our product idea to life is figuring out what we're going to use to develop everything.  This is the first of a number of posts that details what we're thinking about with this process.  First, you'll need a little background about the team.  The Adept and I are .NET developers by trade.  The Style Czar is an Open Source junkie on the server side and runs OS X on the client side.  Since the Style Czar isn't going to be writing any of the application code, this decision is primarily up to The Adept and I.
One of our first thoughts was to use Sharepoint and modify it to suit our needs.  I have some experience with Sharepoint while The Adept is well... quite adept.  Here's a quick list of some things we like about the Sharepoint idea:

1. Not reinventing everything.  This could be a lot of work and using Sharepoint may significantly reduce the amount we have to do.
2. Web Services API to expose most everything.  We have a requirement to support thick client integration.  Exposing the functionality of the system through web services is a great way to support that.
3. It's a technology that The Adept and I are familiar with.  We're doing this in our spare time so not having a learning curve is an advantage.

Those look pretty good to me.  Now let's take a look at the detractors:

1. We may have to rewrite a number of the built in web parts to support the functionality we want.  Remember we said we wanted this whole thing AJAXified?  Well Sharepoint would need some serious help to deliver on that goal.
2. Web part development on Sharepoint is not that friendly.  Since we're modifying Sharepoint, we'd be developing new web parts to fill our needs.  From my experience, web parts can be a real pain in the ass to develop, debug, and deploy.
3. Cost is prohibitively high.  There are all sorts of costs associated with this solution.  We have the license costs for Windows 2003 Server, the costs for MSDN Subscriptions or just Visual Studio purchases, and finally the cost of the Sharepoint server.  This is the kicker.  Here's the pricing page for Sharepoint Portal Server.  Notice the price of The Sharepoint Portal Server External Connector is 30K!

Well that settles it, Sharepoint is out.  It doesn't matter what the positives or negatives are, the total cost of the Sharepoint solution is just too much.  We want to give our users a service at a reasonable cost and we wouldn't be able to provide that with this solution.  Besides that, we're bootstrapping.  Spending money intelligently is a must.
Even though we didn't find the right technology yet, we've identified some of the things that are important.  Here they are:

1. Cost is key.  Because we're bootstrapping we need to keep our costs as low as possible.
2. Web Services are necessary.  We want this in whatever solution we use to support an open API for thick clients to take advantage of.
3. Building off an existing technology to avoid more work than we can handle is important.
4. It would be nice to work with a familiar technology to avoid a learning curve.

I've organized the list so that the things that seem most important come first.  We'll use this to refine and direct our search in the weeks to come.

The Product Idea

A while back I posted about my interest in starting a microISV with a few friends.  We've been delayed for the last month because of various vacations and personal things, but we should be able to jump in over the course of the next few weeks. 
I had been debating about how much to tell of the product before we have anything to show.  After some thought I've decided that I'll just talk about the product before, during and after development in addition to the other business related things that may come up.  Here are the reasons I've decided to be very open about it:

1. The product isn't new or revolutionary so I have no risk of stolen ideas.
2. Posting about the product before and during development will give me more to talk about thus increasing the number of posts here.
3. Posting about the product gives me a chance to think through some of my ideas and possibly identify the bad ones.
4. On the off chance someone reads all this and has valuable feedback to contribute.

The only real reason I was hesitant before to post about it is that there's a greater chance of making a fool of myself.  Well, why not just throw caution to the wind?  Without further ado, the product:
Boiled down to the most basic sense, it's just a CMS/Portal application.  I know what you're thinking: "do we really need another CMS?".  I think we do, and here's why.  I love CMSes.  I think they're great but there are a few problems I have. 
Problem 1:
I want a CMS for me as a personal user, not just at my company.  I also want one that isn't a pain to configure and doesn't have me worrying about which hosting company to go with, what modules to install, and how to get the thing running smoothly.  So, here's goal one:

• Create a CMS that focuses on regular users instead of corporate ones.

Note:  to me this means that the system will be managed and hosted by us.  No install, configure or setup.  Just a simple web page to get you started.

Problem 2:
I want a CMS that is fully AJAXified.  Take Sharepoint for instance.  The simple act of creating new lists, adding and editing items, or changing the layout/design of a site on the fly is a pain!  Many things could be improved there.  So here's goal two:

• Create a CMS that takes advantage of AJAX style functionality wherever appropriate and possible.

Problem 3:
I want a CMS that supports integration with a thick client.  I don't currently know of any open source options but the Sharepoint/Groove combination offers this.  The only problem is that it's prohibitively expensive for a regular user as well as not that easy to set up.  If your corporate IT department is handling everything then you're fine, but we're not targeting corporate users.  Now obviously, Groove is more fully featured than any initial version of our thick client would be, but we can fit in some basics.  Let's split this out into goals three and four:

• Create a CMS that makes it easy to enable thick client applications to interact with the system.
• Create a basic thick client that gives the user the capability to keep the content on their desktop and the CMS synced up.

Problem 4:
Users have content spread out everywhere.  I personally have content and data on multiple systems in my home and work as well as various web services/applications on the net.  I want a CMS that makes it easy to pull all my data together in one place.  Sounds like goal five to me!

• The CMS should support integration with other on-line services and data from multiple places.

Problem 5:
The CMSes I've seen are all designed with the IT guy in mind.  The IT guy only deals with the damn thing when it's being deployed and when a user has an issue!  Since our service is going to be managed and hosted by us, let's focus on the people who will have to use it every day.  So my goal six is nice and fuzzy:

• Create a CMS that is focused on the day to day user.

Problem 6:
Waiting for new features and bug fixes is determined by the release schedule for the CMS.  Well we're hosting and managing this thing so can't we make it a bit more agile?  Yes we can, goal seven:

• Design the system to handle frequent bug fixes and feature releases.

Here's just another miscellaneous goal I have which I won't associate to any specific problem:

• Data belongs to the user.  Make it easy for the user to access their data/content and don't lock them into the system.

 There were other things I had in my head but they fell out while writing this post.  Right now, we're examining what technologies we should use to develop all this.  I'll be posting more this week about some ideas we've had and what way we're leaning.