I believe in Open Source. I use Open Source. I am into it. I am, however, fairly disorganized and highly ADD, as well as just a little bit OCD. I have always wanted to contribute code to an Open Source project, but I've never been able to organize my code well enough to package it for outside consumption. Its a pretty intimidating prospect to me. Whenever I use Open Source code in my endeavors I try provide appropriate credit and to follow the appropriate licensing: whether it be GPL, Apache License, Creative Commons, etc...

As I've said before, I don't believe more functionality is the magic bullet - it is implementation of the right features into an effective package that makes the difference. Much like a Linux Distribution if you will. You can pick one package here, one package there and bundle it together. It will be very useful for a certain type of user while others will prefer a different distribution. That's how I've tried to model the Enfuse toolset. Its about the community, the right balance of tools and interaction. Social Media is not an arms race but users still have to have the right tools to make their relationship with us sticky and our tools must be strong enough to be of value in their self-promotion and collaboration efforts.

Most of our tools have been custom-built, not proprietary mind you... but built from the ground up for use on Enfuse. Many of these individual components I would be glad to share with other programmers but, as I've said, I'm just too disorganized to manage an Open Source project. So, if there's a tool that we have built that someone would be interested in repurposing, let me know... For example, our slide show manager has been something I've considering posting on RIAForge for some time, but I've never cleaned it up well enough to actually post it... The other piece is - there are just better people out there to manage a purely technical project - I'm into the arts and the publishing side. For me, technology is just the vehicle.

[More]

I've been conflicted for a few days now as a result of a fuse mail I received from one of our users. It was a reply to my note about the resume builder. Here, in part, is the response:

" Thank you, that's very helpful, in theory. In practice, however, I thought you should know that Enfuse is painfully slow on most occasions. I'm not likely to become a regular member of this community if I encounter such long delays in navigating around the site. I hope you'll take this as constructively and non-whinily as can be imagined, as I am not normally a complainer-kind-of-person. I actually think enfuse is really great and I just hope that if you ever have to choose between buying something new for the enfuse staff lounge, like a big HD flatscreen or a pasta-maker or whatever, versus buying a new X server, or finding a new/better webhost -- I hope you'll go with a better server or a better host. What you've got going now just doesn't seem to be working out for you. "

First off: OUCH. That hurts. Secondly... thank you. Thank you for your honesty. Thank you for not being afraid to tell us the painful truth about difficult problems. Thanks also, for your perception of us. Wouldn't it be cool if we had a staff lounge, let alone a big HD flatscreen or whatever. The truth is, we're a virtual team, working pretty much for free, trying to build a grassroots company because we believe in it. We have limited resources, all of us have dayjobs, and we have no salesforce.

That said, we have confidence that we offer a valuable service, that our business model is sound, and that we will keep growing. There is no reason to believe that we can't be hanging out by the HD flatscreen in the employee lounge brainstorming about the future of publishing and social media.

The conflict that arises is when perception and reality collide. When we are percieved as big, but people experience lag or feel as if we are unprofessional, it is much more difficult to resolve than if they know they are dealing with a hobby site. However, if we act like a hobby site, and we put out the message that this is just a side-project, will people feel disenfranchised, underwhelmed. Will they feel like they're not ever going to get anywhere working with us because we're not going anywhere?

Or, do we advertise our lifestyle company background, our indie backbone, our bootstrapped financial situation and get people motivated about building something from the ground up.

Well, we are not a hobby site. We have every intention of making this company. There is a clear business plan and a strategy for making money that we are actively implementing. However, until we begin to really bring cash in or look for additional financing, we can not afford to spend much more on our infrastructure.

That does not mean that we should not take action to fix problems with lag. I took the poignant comments made by this user to heart and I took a hard look at some of the areas of the site that were causing slowdown. We had a couple of tables in the database that stored historical data such as past events and usage logs that were massive (gigs of data). Accessing any data out of these tables was causing a serious drain on resources. Yet, this data was being used for some nice (though not crucial) features - such as past event info, bands who have played at bars, article view status for featured artists, etc... I didn't want to lose all of this data and throw away those features.

In some cases - the past events, for instance. I went ahead and simply threw away the functionality. In this case, I figured that the speed increase was worth the loss of the feature. In the case of the article view stats, I reworked the way we did that. Then, I deleted the data - all of it. It hurt a little, I have to admit. After that, I went through and did a partial audit of the site and looked for other areas that we can make improvements. I made some changes and have identified others that I intend to do. The result is pretty significant. I hope that you will find the site to be far more responsive, quicker to navigate and user - friendly as a result of this clean-up effort. And, I did it without getting that X Server.

BTW: We did upgrade our host several months ago and are now on a Virtual Private Server. It may not be the fastest or biggest one on the market, but we're not being cheap or bush-league either. That upgrade was a signficant effort and a major milestone for us. It also had a pretty significant impact on our performance, so, we are moving on up.

So, lessons learned:

• Sometimes you have to do some cleanup
• Some features are not worth their weight - don't keep the baggage
• Perception and reality don't always play nice

I am curious, regarding the perception vs. reality question? Where does one stand. Do you posture as if you are already established because you intend to be, do you just let people decide for themselves and not say anything, or do you give people the sense that they are helping to build something from the ground up in order to inspire a sense of collective ownership?

Over and over again I've been learning, and even preaching, but not always practicing the lesson - don't over-engineer it. Build something simple that works well - test it, use it, enhance it... Not only has over-engineering been the cause of so much paralysis of analysis, but it has also caused a lot of wasted time and energy and more than a few big endeavors that got almost no play.

Here's an example. Years ago, when Friendster was the big Social Networking site to watch, and I was still building our fuse tools, my vision was to make several layers of relationships - User to User, Performer to Performer, and Performer to User (ie: fan). Seemed to make sense considering our model allows a user to have multiple performers registered under a single user account. That way - Band A could be connected to Band B and a member of Band A could be connected to a user in Band C. That of course, was in addition to being an associate - meaning: User A is a member of Band A and Band B - thus has admin rights for both bands. Phew... Sounds complicated doesn't it? Exactly...

It created a fairly convoluted build, and unfortunately, negatively impacted usability. People don't want to see all the complexity of the various relationships that are possible. They only want to see the functionality that is most relevant to them. In the end, I blame this over-engineering, in part, to the slow adoption the tools have gotten. Now that we have made some navigation and usability enhancements and are reaching other critical mass milestones the networking tools are getting used, but most users are just using User - To - User fusion - the standard and familiar model across Social Networks. Meanwhile, the other networking relationship types have seen very little usage, but are a continued maintenance exercise. In hindsight, it would have made sense to just introduce the familiar networking type, fine-tune the usability, then roll-out the other types.

A lesson that I am learning from many new Web 2.0 social sites is to focus on one thing and get it working. Make sure people actually want to use it. If its simple, then there's no excuse for adoption if it is a good idea. However, even an excellent idea that is too complicated can fail because its just too difficult to figure out.

Woohoo! It took more than 3 times as long as I had expected, and I probably made some stupid choices along the way. But, we're live. The site feels faster. Logins are truly perpetuating as they should be. We're dedicated now, on Linux, with an upgraded database server and lots of little fixes that should help us grow.

We're finally truly able to offer branded sites now, and know that we have the capability and infrastructure to support both our growth and the growth of our clients. I've been very happy with the help we've gotten from our host Vivio Technologies as well. In the end, we decided not to go with our preliminary hosting partner due to differences in our site hosting vision and concern over their ability to really support Blue Dragon. I'm confident we made the right choice.

It was really a pretty massive undertaking. And, I have to admit, I was pretty wiped out and ready for a break when it was done. The killer is all the little things. Sure, it can take some time to rewrite certain components or to port from Windows, but it just gets so tiresome to stumble on lots of broken images, missing files or just strange sql incompatibilites, or Macromedia vs. Blue Dragon differences, like cgi.path_info for instance.

The good thing was that in the process, lots of little stuff that has been hanging around for years has been cleaned up and functionality that was similar but written differently in different areas (such as file uploads) was made consistent. This should help us be more agile moving forward.

It was very exciting to see us move from one site to the other - to turn off login on the old server, and by the time I checked, we were up and running at the new domain with a handful of new users registered and strong activity site wide.

I'm sure there's still little stuff floating around that needs some tune up. Broken images, missing files, broken links. Please let me know if you find any. Its gotten to be a pretty big site. We also had a bit of trouble with email for a short while, so if an email you sent us bounced, please give us a holler and let us know.

Now that that's behind us, and I've taken a short break :) watch for lots of new features and enhancements. And please, if you have suggestions or find bugs, please let me know.

It is in my nature to jump on things and run full speed ahead. That can inevitable cause irksome issues, especially in a situation like this, when we've now got pieces of Enfuse running on 3 servers - Enfuse.us, EnfuseMusic.com, and of course, EnfuseMagazine.com.

Though we knew pretty early that Enfuse.us was not going to work, it was a great place to setup CFMX capabilities that we could not run on the Magazine server. Since I really wanted the Wiki and Flanagan was rearing to go on the Blog (as was I), it just made sense to get it up and running, especially since we didn't know long it would take to find ourselves a new home.

Now, I've got to consolidate code from 2 servers, and data from both... and make the move as quickly as possible. Otherwise, I make changes in one place, data gets update somewhere else, it will never get consolidated.

All that aside, this week has been a satisfying challenge in trying to move everything to a Linux platform on a BlueDragon 7 server, MySQL 5 database, and doing it all from a restricted IP without FTP access using only command line. That was the deal so with our dedicated server, just until we confirmed that we wanted to move forward. It helped them keep everything wide open to us without exposing themselves to the rest of the world while we configured the server. It's been pretty cool having root access and server admin rights to Enfuse. It's about time!

Just got back from lunch with a potential hosting partner. They're not specifically a hosting company, but rather, specialize in custom applications and support of other apps such as Fraud Detection software, etc... They inherited some hosting clients and weened them down to those for whom they don't have to do any web development. Through some connections, they had stepped up as potential candidates for hosting Enfuse in our big move to a dedicated server.

They were sincerely interested in the Enfuse Co-Branded toolset for hosted clients. The owner expressed that they would be able to build out some of the automation for setting up hosting so that our branding tools could integrate with their hosting tools and we could have a mostly, if not completely automated flow for Co-Branded clients.

Since they are moving into a new data center, they will be freeing up a box and building a fresh operating system for us. We're looking at going Linux with Blue Dragon. We are also going to try putting FFMPEG on the box so that we can explore Flash Video encoding server side.

If things go well this could be a really great partnership. In addition to interest in our business model and a mutual benefit from Co-Branded hosting, they have some interesting products. One is FinderWare - client software that helps manage a book library. We discussed how this could be extended into social tool as well...

Once the basic functionality was worked out, there remained the presentation layer and media players to consider. Open Source is a beautiful thing, and with a bit of browsing and experimenting with several codesets, I found some flash players that I really liked. Simply allowing media embedding gets awful ugly quick. For one, that stinkin' Active X alert on IE 6 and down is very annoying, further, the autodownload causes serious problems when you're trying to upload another file and just uploaded one... And ofcourse, losing control of presentation is always a problem. Its so hard to know whether Windows Media, Real Player, Quicktime, Winamp, MMJ, or what will start playing an embedded MP3.

The XSPF Web Music Player seemed by far to be the best of the few that I tried: http://musicplayer.sourceforge.net/. It has some cool capabilites and is designed to work with playlists but can receive single files - I only realized that after I spent too much time trying to make playlists just for single songs. I am a bad documentation reader. In addition to the player, I found some PHP code that can parse the ID3 tags of MP3s and build xspf playlists. Of course I was the first one to try it out and the results are here: Sasha's Artist Profile. Thank god for Open Source. It lets us focus on our core business, plug-in cool tools, and hopefully share the love.

I also learned a cool little trick regarding CrossDomain XML and Flash. It turns out that you can bypass the security issue by placing a CrossDomain.xml file in your web root and specifying the Domains that can share XML data. That enabled me to build Artist Spin. This will eventually allow visitors to listen to all music by any artist. It grabs XML from EnfuseMusic.com and lets it play on EnfuseMagazine.com.

I also found a Common Copy FLV Player Still need to figure out how to do server side encoding to FLV - that will be more realistic once we're off shared hosting platforms.

Now I just need to add an Agrees to Terms to the upload app so we at least get agreement that the media is not in violoation of copyright. Here's to hoping that since we're a site that caters to artists, we'll get original content.

In other news, sounds like we have a lead on a dedicated server that falls within our budget. WebHost: Segora. A lead through family in the IT security business - www.toolcase.com. It would be suge a huge relief to get on decent hardware, consolidate and be able to use the full functionality of Cold Fusion MX. More on that to come.