Communication, Vision and Planning

We need to start having weekly meetings to touch base and make sure we're all on the same page and are maintaining the same vision. I'm quite frankly worried regarding this point.

There are two distinctly polar views regarding this software. We need to get behind one camp and support it fully. We should not continue to tiptoe around the periphary of this issue, or we're going to loose developers and end users, and the project will become yet anohter failed or niche open source project.

On one hand, there's the desire to try to be all things to all people, and supporting of browser specific enhancements. I honestly don't think it's the right time to start offering different support for differnt browsers, as I think it only stands to introduce support issues as broader adoption starts to take place.

Once we have a solid 1.0 release code base and a couple of point releases under our belt, we can start to think about differentiating feature sets. In my view, no one will ever complain about featre parity between the browsers; people will however decide to not use the software because they view their browser of choice as being a third-class citizen. It's just the way the psychology of these things work.

Secondly, we need to base our decision on who our primary target market is. I can best illustrate this principle by borrowing from Shayne Bowman and Chris Willis, Peachpit authors and web developers who know a thing or two about building successful sites. They are strong advocates of profiling your target market and building to satisfy that target market, not everyone.

Traditional approach
To attract the largest audience, sites add many features and services. The problem with this approach is that it will compromise one customer's experience for another's. As a result, most leave with an unsatisfactory experience.

Profile approach
Focusing on a great solution for one person increases the liklihood that you will have creatd a better solution for many others. Of course, you'll never please them all.

I'm a huge advocate of the latter approach, have experienced success using it personally, and can offer 37signals as just one example of someone that uses this approach and is really successful with it. IMO, it's the way it should be done.

In our context, that means we need to have a discussion now of what really belongs in the core and what should be implmented as a plugin. I'm in the camp that thinks the core of the application really should be lean and geared towards serving the ultimate needs of enterprise-level applications and security.

I can and would take something like this to IBM, and will have the opportunity to do so when I as my friend who is one of the Global Services managers there. It a targeted solution that doesn't require a lot of hemming and hawing and explanation about. You simply present it as "here's what it does", show it doing that exquisitely well, and watch their reactions (probably very positive). They are actively lookig for things to support that can help combat Microsoft in the realm of .Net and Sharepoint server. They're also investing heavily in Linux, Open Source and PHP right now. (We can always create "plug-in packs" that provide non-critical effects and browser proprietary enhancements later on or even release them simultaneously with the 1.0 release.)

My goal to have the opportunity to at least try to get IBM's interest in our project by presenting to a group of decision makers there, not just my friend. In orde to succeed in this, it'd have to be done very much like a VC-pitch, and based on my personal experiences with those (including at Sevin Rosen who was the lead VC for little companies like Netscape and Compaq), there will have to be some very difficult and hard decisions made, then we will have to execute flawlessly against those decisions showing focus and excellence in their implmentation.

I don't really expect to have any direct support from IBM upon making this presentation. However, what it would represent is serious validation of the project and an opportunity to meet some people who might just be able to become evangelists or fans of our project along the way. In the end, I want a project that is sustainable and that will be here years down the road.

In summary, here's the short version of what I think we need:

1) Clear vision and direction regarding architecture and what's in the core (and everyone on board with and working towards that end goal)
2) Clearly defined target market
3) Enterprise-class scalability
4) Development team "rules" (meeting/group chat requirements, IM clients, Skype accounts, Subversion, coding standards, expectations, etc.)
5) Public communication about the outcome of the above

We've got one heck of a foundation and I hope we can rapidly reach consensus and move on to more proactive and focused efforts.

Personally, one of the concerns I have is the decision making process regarding the marketing of the software. I'm not exactly sure who is in charge of delegating, nor what my responsibilities are compared to or against anyone elses.

I'm fine with taking whatever role it is the team sees fit for me, but I feel that even though we are open source, we HAVE to have some sort of hierarchy/reporting system so that people have clearly defined roles/paths.

Based on what you are asking, it sounds as if there is a strong need/desire for a full-fledged business plan. Any time you go after major sponsorship/partnerships, its a great idea to have one.

modsandrods.com has a 27 page business plan we devised. It got us our 501c3 status (under new, very tough IRS restrictions) and it looks like a partnership with Warner Brothers studios this year (unannounced as of yet).

- J

John,

I think you're definitely on the right track regarding the business planning. And a lot of the inputs for said plan will definitely come from identifying the opportunity (what our product, and how it will do it differently) and who will "buy" it (our target market). From there, we need to get our collective marketing wheels in gear and figure out how to best evangelize the solution.

Regarding where the "reporting lines" lead to, I'd say that as of right now that would fall between Raymond and myself. I tend to focus much more on the marketing and strategy side, as I'm not so hot when it comes to PHP coding (CSS/XHTML is another issue). There's no real formal structure as of yet, but its probably time to gel one once we define what the heck Tattoo will be and who it will serve (see previous paragraph).

Does that sound reasonable, or in your experience have you seen other models work more effectively?

I'll expound a bit further later but for now I've been very consistent in my desire for Tattoo to be focused squarely on content management. I get nervous with the definitions and comparisons of .NET and Ruby on Rails. I think the reason that no open source CMS has risen to dominate the marketplace is because of this desire to be too many things to too many people. If you're looking for adoption at the enterprise level this is key. IBM doesn't care about polls and phpBB integration. They want to see workflow, versioning, LDAP and structured content editing; key CMS checklist items. Various open source CMSs are at various points with these currently. No one brings it together in a simple to install, simple to use package.

Very good points Dave, and well taken. While we're nowhere close to even being able to entertain a presentation to IBM, I can say from my discussions with my contact there that they are very much looking more "down market" and are focusing on that as a growth opportunity. It gives them a growth path for upgrades to their serious Database and other offerings.

However, what you're talking about is right on, with respect to core functionality for true content management. In the interim however, the things you mention as having no value to IBM happen to put food in front of my kiddo and wife. When and if we ultimately go to IBM for that hypothetical presentation, they should be implemented as a plugin and not part of the core IMO.

Well my regards about IBM were mainly as an example of an upper-tier, enterprise company. You could substitute anything like Ford or Pepsi in there. Those requirements would be the same. Your point about feeding your familay are understood I think sometimes I've worked on so many large scale projects, I don't understand the smaller-scale space as well.

Well I'm all for structure and the new business plan. Weekly meetings? I'm not sure how that will work with our different time lines.


IMO some of the underlining features can't easily be explained.They must first be demonstrated in order to show how they will all work together.

Tattoo can be viewed as a fully equipped BMW which to most users it's just seen as a car. The beauty about it is that you will not see most of the features by just looking at the dashboard.