MakeThePath Blog

Freinds of MakeThePath, the day is finally approaching. MakeThePath is about to go live! That’s right. after much discussion about integrating the platform in other applications we decided to just let ‘er rip. As they say if you want something done right you should do it yourself. So here we go.

For the new release, we’re starring with fresh accounts. So if you were part of the prealpha just sign up and choose a password of your preference.

I’ll post here when we’re ready to go.

Scott

We received a lot of excellent feedback from the volley of the friends release.  In addition to many suggestions on the interface, we had the chance to see it running under some truly horrendous conditions and have been working on speed and size. But there are more noticeable changes too.

A new interface motif

Initially we arrayed the Paths on the stage and you would slide left and right by dragging, using the arrow keys or the “compass” at the upper right.  You could jump directly to a Path using the”Left Paths”/”Right Paths” menus at the bottom of the interface.  We decided to simplify the visuals a bit by focussing on a single Path at a time.  you still move in and out as before, but if you want to look at other Paths, you choose them from a pop-up menu at the Bottom left of the display.  As you select individual Path names from that menu the Paths pop up on the stage so you can see if they contain topics you’re interested in.  It simplifies getting to the Path of interest, and is a pretty neat way to see what the structure of the various Paths looks like.

Introducing “Interest Groups”

We’ve always realized that other interest groups outside of the sustainability space would be interested in having a tool like MakeThePath.  This will probably be our best initial selling point, and to demonstrate this we’ve created two new interest groups: Acoustic Guitar, and Artist Resources (you can guess why those were the first two).  In each of the communities users can help each other by sharing their best resources for information on these two topics.  Each group works just like the MTP sustainability site, with users allowed to add content, and that content then offered to other users as recommendations.  In fact, your MyPath comes with you from interest group to interest group, so your favorite links are always handy.

Because the MTP recommendation engine captures the zeitgeist of each community, we think there will be many similar interest group communities that people may want to form and contribute too (the ning.com model).  These first two are for fun, and I find myself using the Acoustic Guitar group quite a bit.  We’re currently looking for other groups to demonstrate the platform, and I can’t help thinking that our friends group has some great potential applications (anyone interested in creating a content-space for Investment Banking for instance?).

Performance tracking in this release.

In order to understand how the program is running on different hardware, we’ve added performance monitoring to this release.  After the first Path has fully loaded, please click on any of the content icons to show a preview of the content.  That’s all you have to do for us to learn how the program is performing on your computer.  It helps the effort a lot, and we appreciate it.

Here comes the cash.

After we have some more data from this release, we’ll be sending out the surveys (your chance for a coveted Amazon gift card).

Thanks everbody.  We couldn’t (and wouldn’t) have done it without you.

Scott

At 3:50PM Eastern we pressed the send button on a raft of email invitations to our insider’s release!

Jason and Karthik have been implementing new features right up to the last minute, and Brian Romer (of RomerCreative) brought in a whole new design for the intro page and supporting pages.

We continue to work on features as the users begin to sign-in.  We’re looking forward to their feedback, and to getting marching orders for improvements and features.

Thanks to everyone on the team, and especially to those insiders that are giving of their valuable time to help MakeThePath reach its potential.

Scott.

MTP Ramps Development

A lot has happened since our last installment, and as we approach our first release (that means you…), we wanted to share this update.

The Best and the Brightest:

Our most important news is that we have two new and important contributors to the project: Jason Brubaker and Karthik Thiyagarajan, both of Carnegie-Mellon University, Scott and Dave’s alma mater.

Jason is by his own description a “non-conventional student” having returned to finish his B.S. in Computer Science at CMU after several years in software development.  Jason has been a part of and has led development teams at ImageVision.net, where he was engaged in the design and implementation  of web applications both on the server-side (i.e. database architectures and communications) and the user side (i.e coding the browser).  Jason brings a host of skills to the project, he has a good eye for design, both visual and software, and likes to “make the browser do things that people didn’t think were possible.”  We’re extremely fortunate to have Jason on the team, where “non-conventional” is a virtual job-requirement.  He has already made significant contributions to the project, having made adding content much easier, and improving the cross-browser compatibility of a key aspect of the site (a necessary evil in this business).  Jason will be key to bringing our powerful, easy and fun-to-use interface to the MakeThePath community.

Karthik joins us from CMU’s Information Networking masters program, where he’s been focussed on applied data analysis, statistical methods and machine learning (including social network analysis methods).  Karthik  is our first summer intern, and will work with us over a twelve week period this summer to establish the algorithms that will make MTP collaborative, engaging, smart and even surprising.  Karthik is interested in helping a company bring a real product to market, and with MTP he’ll definitely have that chance.

Jason and Karthik bring complementary skill-sets to the project and will lay the foundation for scaling the platform technology.  They have already contributed in important ways and will help us get our first release out this summer, .

Addicted, but in a good way:

The interface to MakeThePath continues to evolve, and as our first insider users begin to work with it we already have an indication that it is both useful and fun.  As one of our co-founding team said “it’s my new addiction!”

On love, and financial modeling…

We continue to follow an unconventional path toward building and financing the business, which has us seeking funds to finance a Beta release scheduled to occur around the end of the year.  That means developing detailed financials, and we are in the process of developing our models right now.  Even altruistic investors want to know the bottom-line, even if they have more than one!  We’re hoping that with the alpha user experience and the development of the revenue platform we can attract investors interested in the social and environmental aspects of project as well as an established revenue and user model.  Times are pretty brutal in the seed market, but we are optimistic,  in fact, now that we’re using the technology ourselves, we think we might have a tiger by the tail.

I hope to be sending a formal request for you all to join the “friends alpha” release in mid-June.  In the meantime, we’ll be updating this blog with items about our progress toward the release and tweeting at @MakeThePath on Twitter.  Look for a post soon on our use of Engine Yard and Amazon’s Elastic Computing infrastructure, otherwise referred to as “the Cloud.”  This approach is very cool technically, and more importantly allows us to provide users with a quality experience with little to no capital investment on our part (which actually makes the financial modeling a little unusual). (<- potential investors, see that last part?  Low capital equipment requirements.)

As always, thanks for your support.  We look forward to having something fun for you to use and give feedback on in the near future.  And, if you know anyone who’s looking to invest at the seed stage of a green-tech company trying to change the world one user at a time, just forward them my e-mail! (was that a solicitation?  I’m sure my lawyer friends won’t hesitate to let me know…).

All the best,

Scott, and the MakeThePath team.

Earth Day? With a mission like ours it seems that an Earth Day entry would be mandatory, and I guess this proves it! But, it should surprise no one who knows the project and the principals that we’d have something slightly different to say on the topic.
Isn’t it odd that we have a day to celebrate a planet without which celebration itself would be impossible? We understand how important it is to put attention on something that people take for granted. Like Breathing Day raises awareness of Asthma and other illnesses that make impossible something most take for granted. We get that. But we can’t help feeling a little sad that that Earth is so taken for granted that we have to have a Day to remind people of what they depend on like (and for) breath itself.

Earth, it’s not like there are other options. Perhaps someday it won’t be necessary. But until then we all do our part and wish our only beloved planet Happy Earth Day!

At a recent MIT Enterprise Forum Digital Media SIG meeting, two presenters from different corners of the mobile-web space discussed their perspectives on how the mobile experience is unique, and that raised some interesting thoughts for MTP and other similarly situated “new media” projects.

The presenters were Jack Kelly of Adva Mobile and Jon Cooper of PhindMe.  Each has a different approach in the mobile space.  Adva uses SMS messaging to connect bands to their fans.  Fans can sign up to subscribe to an SMS “feed” so their favorite bands can announce local events and releases, etc.  Adva also scrapes the band’s MySpace page to create a mobile presence for them.  PhindMe works with the umpteen businesses that haven’t yet created a mobile version of their web-site.   Some relevant factoids, and issues from the presentations.

1. Only 0.2% of web-sites are mobile optimized.
2. Developers should consider the difference in the physical environment of the user when using a mobile device.  They are more likely to want a map or make a call than to want to browse a product catalog.  The user is in a different context, and the interface design should reflect this (and most current sites don’t).
3. Understanding that users will often go to their mobile phone on first hearing about your product.  What impression will they get?
4. The portable device can be more personal than their PC (the immediacy of personal phone calls makes the device more intimate).
5. People fire-up their phones to get “now-content”  sports results, news, streaming.
6. The idea of “snackable” content.  Short snippets of content that people consume in short fugitive moments with their phones.
7. Mobile search is different in that the question is often “what’s nearby” or “give me the phone number for X.”  Can a user click to call?
8. From a design perspective, the aspect of the screen is generally vertical, though the iPhone and G1 phones are changing that.
9. Location provides a new form of ad-focussing to increase revenue per impression.

A long discussion among the SIG members ensued with a recurrent theme that the U.S. market lags the international market in almost all respects.  This was especially true for the integration of the phone with real-world purchasing.  In many countries including India and Japan, the phone becomes a kind of electronic wallet, and it is used to make even the smallest purchases like buying a coke.  This is an important new mode of revenue for content providers because it shifts from an impression-based model to transaction-based model where even a small part of the transaction could be quite valuable.

I think these lessons are especially useful for MTP.  In creating a mobile interface we’ll keep the following in mind the special power that adding a mobile interface to the project would have.  Adding MTP content while out in the world, and having MTP content surfaced based on location would be a blast.

It’s become time to begin development of the server-layer.  Without giving away any details, MTP requires quite a bit of ongoing communication between the server and each user so that the user environment is kept current, and so that user feedback is propagated to the community (<- now, that doesn’t give anything away really, but doesn’t it sound cool?  It is cool).  I have years of perl programming experience, and have never used an App Framework before (I’m just too non-conformist I guess), but when I decided I wanted to enable OpenID authentication (more on this later) it occurred to me, “someone must have worked this all out before.”  So I went hunting for a framework.

Let’s cut to the chase, I’ve chosen Ruby on Rails (or Rails as the cool kids call it).  Here’s what I was looking for, and why I made this choice.

1. I really hate to say this, but perl is getting a little dusty.  That really hurt. I’ve been using perl for years, and the incredible development community that contributes to perl through CPAN has saved me on more occasions than I care to mention.  Let me go on for a bit.  I find that it is easy to write beautiful code in perl (apparently it’s also easy to write ugly perl code, but that’s not perl’s fault).  When I was first introduced to the DBI/DBD and CGI modules back in the 90s it was the absolute coolest thing ever.  Then later, when I moved my app onto  mod_perl and MySQL in RAM  it was just insanely fast.  Ridiculous.  Huge queries coming back in 1/20 of a second of user time.  I was convinced for over a decade. But, when I went to implement WebKit and OpenID in perl I found the modules a little shall we say &quot;underused.&quot;  So reluctantly I began looking around.
2. I’m ready to conform to a framework if I can use it as intended most of the time (i.e. I’m not always coding exceptions to the default behavior of the framework).
3. I want the underlying language to be as well supported as perl through CPAN.  When I ask, &quot;I wonder if anyone’s written a library for scraping web-pages that require authentication.&quot; I don’t want to end up with a semi-roll-your own solution.  Perl has this sort of thing nailed (mostly) and I’m not willing to give that up.
4. Standards evolve, and so I need libraries that are constantly being used, fixed and updated as web-standards change.
5. I will not ever, ever read a string by parsing it character by character again.  In fact, I don’t even want to have to call a function to determine if a substring exists in a string.  Perl has forever ruined me for this sort of thing.  I want chop, split, join, //,  s///, tr///, =~, etc. etc. (the perl geeks will understand).
6. I want mod-perl like integration with Apache (or another industrial strength web-server.  Is there another industrial strength web-server?).

So I pondered, and looked at a variety of choices.  I wish I liked java better, but it gives me bad C memories.  The easy things should be easy, and no one has shown me that this is  the case for java.  It meets almost all of the other criteria given above, but I just can’t bring myself to load a whole raft of libraries to get the basic features of what I consider to be a modern language.  Having said that, please (please) prove me wrong because I know that many (most?) hard-core sites are developed in java.

I pondered python.  When Google’s App Engine runs only python that should tell you something.  Also, I’ve seen some really cool science applications done in python so that seems like familiar territory.  Library support looks modern and current, and speed seems good.  The Django app framework also looks worth more investigation, but it seems less well documented than Rails.  Python/Django would be my second choice now (and who knows, it may become my first).

I’ve never loved PHP.  I’ve done a lot of work in it, and if someone could convince me to take a look again I would (since I hear the frameworks are pretty good), but I’ve never loved the template origins of the language (i.e. designed from the beginnings to be web-embedded).

I then discovered ruby.  This is where many others  would insert an ode to ruby’s elegance. I do find ruby elegant, but more than that,I find it familiar as a perl programmer.  This allows me to get up to speed quickly, and that’s important at this stage in the project.  As to the elegance point, let me just say that yes, you can definitely write ugly ruby code.  But it is the exception.  And of course there’s Rails, the hottest (hopefully not in the Paris Hilton way) web application framework around.  I figure if I’m finally going to conform I might as well conform to a system that is deep and full of lore and mystique (but not silly secret handshakes).  Having brought the server layer up in Rails, here are my initial thoughts.

1. www.railscasts.com is an awesome site.  Screencasts are the new thing for me, and I think I’ll be doing much ot the MTP documentation that way.
2. in ruby, the easy things are easy, including reading in the contents of a web-site and parsing it. Connecting to databases and mod_rails, all the stuff that  was so cool back in the day?  It’s all too mundane to mention now, it just works.
3. The Ruby  libraries to internet stuff (like OpenID) are current, well used, and thus well tested. They work.
4. You get sessions, authentication and REST-ful architecture for free.
5. It’s big and slow.  I’m looking into this, and some (though not all) of it seems to be my fault.  But on it’s best day, with the ethernet winds at its back, it does seem to take just a little too long to serve a simple request from the database (hitting an indexed column).

I’m willing to deal with (5) to a reasonable extent, since I remember how c programmers used to deride perl users for how slow the langage was.  &quot;How could you even think of using a scripting language in production.&quot;  Time has shown that to be a pretty weak argument, and I expect the same to become true for ruby and Rails.

I’m currently looking to better understand the performance of MTP when confronted with real users doing real things with the interface.  I’m in discussions with Sun to use some of their profiling tools to analyze the performance of my Rails stack and compare it to other framework options, and I hope to do this work before my commitment to Rails becomes too costly to reconsider.  In the meantime, I am enjoying Rails development so much that it’s finally convinced me to switch from vi to TextMate.  Anyone who understands the last sentence will be laughing and nodding right about now.

In our last post we discussed the various options for hosting a new web-project.  Having chosen a Virtual Private Server model, we then had to wade through the sea of choices.  Our primary considerations

1) Support for Linux-based systems.  We’ll say more about open-source models later, but suffice to say that we’ve spent the last 15 years avoiding proprietary software, and we’re not about to paint ourselves into a corner now.

2) Cost.  While important, it has also been our experience that you generally get what you pay for and that inexpensive=cheap.  At this stage in our development we can’t tolerate the added expense of having to switch platforms because of poor support.

3) Scalable.  See #2.  We can’t afford to rebuild the system as we approach scale, so choosing a provider that can take us from small-scale virtual system, through to cloud-based (more on that later) or dedicated co-located systems is important for us.

4) a MakeThePath business?  While this is listed as #4, it is really co-equal among the factors.  It is important to point out that having identified a number of hosts that met the first three criteria, it was this fourth factor that led to our eventual decision.  It’s called “walking the talk.”

While I’m sure there are other hosting companies that also meet these criteria, we chose Slicehost.com because it seemed the best match.  

1) It is a “develpers hosting site.”  It is a roll-up-your sleeves operation for people who prefer to ssh in to their site and edit files than to interact through a control panel.  There are many flavors of Unix that can be installed, and the support forums are full of discussions on running fast web-servers, and interacting with cloud resources.  It’s our kind of host.

2) The cost is reasonable, not the least expensive, but not the most either.

3) Slicehost is part of the Rackspace family, and is part of their strategy to provide solutions from small-scale virtual private hosting up through large-scale dedicated, managed and cloud computing installations.  Rackspace has been a player for a long time and has an excellent reputation, having supplied low-cost hosting to several well-respected open source development communities as well as hosting some of the largest sites on the web.

4) Rackspace, and by extension Slicehost is a MTP business.  When I was discussing our needs with our account rep. (yes, a real account rep, just like a big company would have) I learned that Rackspace not only offers green (carbon-offset) computing resources for its users, but also has a comprehensive sustainability policy.  She told me about the many things large and small that Rackspace does to consider the impact of their operations on the environment and the community, and to make the company a good and flexible place to work for their employees at all stages of their careers (Rackspace is #32 in Fortune’s 100 best places to work survey in 2008).  Given her enthusiasm about how the company behaves, it seems that they “get it.”  I made it clear to her that these policies are a large part of the reason that they got our business.  It is the Make The Path way, reward the companies that are doing the right thing, and let them know the reasons why

As we grow from the simple requirements of web-hosting that characterize the Green-Arrow Network web presence (web-site, blogs and email serving) to the more demanding requirements of MakeThePath it became clear that we needed to upgrade our hosting solution.

Green-Arrow has for years used shared virtual hosting.  The advantages are

1. Low cost.  We were paying ~$8/month for web hosting that included 6 domains and unlimited emails.
2. Easy setup for new domains, and new email accounts.  Our host used CPanel, the ubiquitous web-based solution for managing shared virtual hosts.
3. The servers are managed behind the scenes.  The hosting compmany takes responsibility for dealing with hardware failures and the like.
4. Access to IMAP mail servers and web-mail.  This is especially useful for business email since you always have access to your email on mobile devices, and even shared computers.
5. Easy to install packages like Drupal and Wordpress.  CPanel contains a wizard for installing several open-source blog and content-management solutions.

However, there are significant limitations for projects like MakeThePath.

1. Resources are shared, and sometimes not evenly.  On a shared virtual host you are sharing a single processor with other users, and load balancing is not always equitable.  This became a real problem for Green-Arrow when another user on our shared server was hogging all of the allowed IMAP (mail) connections.  This meant that we were unable to connect to our mail servers which is a real pain for a growing company.  Hosting companies can load balance web-site resources like bandwidth much more easily than they can basics services like IMAP.  
2. Lack of flexibility in what packages are installed and how often they are updated.  While CPanel makes it easy to set up a Wordpress instance, it does not allow you to change the version of Apache or MySQL that lies beneath these services.  In some cases, the latest version of Wordpress or similar software will require a newer version of PHP or MySQL than is installed on the server.  Because many other users are sharing these same programs, and switching could break code that they are using, the hosting provider will be very resistant to upgradng.
3. Limited domains.  While 6 domains might sound like a lot, the can easliy be chewed up by the domain variants of your site.  For example, we’ve registered makethepath.com, .org, .biz, .info, .us, and .mobi.  That’s six domains right there, leaving now room for the other domains we would want to serve, like the same variants of green-arrow, and professional web-sites fr the founders.
4. Limited control to install and customize software (i.e. no ssh access).  As described in 3, sometimes you want control over exactly what versions of server software you are running, and what modules are installed in each.  For example, if you are using perl for serving dynamic web-content, then you can get dramatic speed increases by installing the mod_perl Apache module.  On a shared system this is usually not an option.

In order to overcome these weaknesses, we had two choices, use a dedicated server or a private virtual host.  A dedicated server involves the hosting company installing a physical computer that is entirely for your use.  You determine how powerful a machine you’ll need and it is all yours.  A private virtual host is an intermediate solution, where virtualization technology is used to create several virtual machines on a single powerful server.  Each virtual server is logically seperate from the others, and can be configured as though it were a stand-alone machine.  The amount of processing power that is allocated to each virtual machine is set so that no one server can take more than its share of procssing power (unless other machines are not requresting resources, in which case you can utilize unused compute power in burstsmwhich is very handy for a web-server that mioght get intermittently busy).  As you can guess, we chose that latter option.  It has the following advantages for a growing start-up project like MakeThePath

1. Low cost compared to dedicated servers.
2. Flexibility.  You don’t have to determine how powerful a server you will need at the outset, you can start small and increase your virtual share of the server as your needs dictate.  This makes life much easier since you don’t have to buy too much machine for the early stages of the project, and be stuck with too weak a systems when your site becomes more popular.
3. Full control over what runs on the server.  You have full root access and can tailor the server for your particular project.
4. Better fault tolerance than a dedicated server.  The virtual server is hosted on a machine with fault tolerant disks and multiple processors, thus making the system more fault tolerant than a dedicated system that a startup is likely to be able to afford.
5. Prepares you for the world of “cloud computing.”  By looking at your computing resources as virtual and flexible you are adopting the mindset of cloud computing, where resources are applied based on demand.  While this approach is still controversial for mission-critical parts of a web application, it is an efficient way of utilising computing resources, and will likely play a large role in the future for deploying systems where demand may vary substantially over time.  Most start-ups hope that demand will vary substantially, that is, that demand will grow.  Virtual hosting and cloud computing provide easy paths to respond to increasing demand.

 So what host did we choose?  We chose Slicehost.com, a Rackspace company.  In fact, this post is currently hosted on a “256 slice” (the smallest slice offered).  We’ll detail the reasons why they are an appropriate hosting company in a future post, but suffice to say, they provide a path forward for us as we grow, and they are a MakeThePath company, with a demonstrated commitment to the environment both in their product offerings and in the way they run the company itself.  More on that later.

I am just coming back from a meeting of the MIT Enterrprie Forum SIG on digital media.  The session was on consumers social network, and an interesting discussion took place concerning ad-based revenue models in this space. The question was asked: “If your companies are so successful then why is an ad-based revenue model the kiss of death for investors?”

1) Mass-Marketing is Dead (and the internet killed it).

Part of the answer is that ad-based revenue models have been given a black eye by general audience sites that do not form a focussed user community.  In other words “mass marketing is dead.”  If you are serving banner ads to a mass consumption site then you have a very low likelihood of serving anything useful to any particular user.  Combine that with the fact that people will “turn-off” your ads by simply ignoring them and your actual conversion rate will be very low.  That’s why $/impression is usually so low for these sites.  

Google gets around this problem (and achieves relatively high ad-rates, by focussing the ads based on the search terms.  Social sites provide an answer to this problem by creating a focussed audience.  If the ads can be tailored to that audience then ad-rates can be 10 times higher (according to the panel).

2) Facebook (yes, facebook).

The facebook problem is a question of what Hangout.com’s President and CEO Pano Anthos calls the “modality” of the site.  Why are people there? For facebook people are there to catch up with freinds not to buy things. Because of this re banner ads on facebook have a notoriously low CPM. Pano’s gave a hilarious analogy to men’s room advertising.  ”I’m just not there to buy things at that moment.”  So the modality of your site is important as it relates to what kinds of ads will work.  An example was given from the mobile platform mocospace.  People are on the site to interact with their friends much like facebook in the mobile setting.  In this context the best form of advertising is not to advertise products, but rather to inform users about brands.  Forget click-through, you just want to inform, and support the site and the environment where the users are spending their time.  So their most effective ads are album releases, movies etc, where they’re not expecting people to actually make a purchase, but just to become aware of the brand.

3) What kind of ads are they anyway?

Finally, there was the great point raised about click-through and click-to-purchase advertising on the web.  The largest and most well understood form of brand advertising occurs on television.  This is not a click-through or click-to-purchase medium and it has done quite well with advertising and vice-versa.  The same is true of print media.  The ads inform you of something, and that is their purpose, not to get you to make a purchase while you’re watching or reading.  The web need be no different.  In other words, everything old is new again.  

The name of the game is creating an audience that will be receptive to the information in the ad, presenting information that the audience won’t immediately ignore.  The rest is old-school.  Everything old is new again.