Make money from open source? Umm, no.

Image by rigeneriamoci via FlickrOn Open Source:

Companies have long hoped to make money from this freely available software by charging customers for support and add-on features. Some have succeeded. Many others have failed or will falter, and their ranks may swell as the economy worsens. This will require many to adopt a new mindset, viewing open source more as a means than an end in itself.
- Open Source: The Model Is Broken

Umm... Duh.

Let's look at a couple of the premises of Open Source.

1. Open Source code is higher quality
2. Anyone can modify it
3. The more successful the software it, the larger the community.

Now, lets look at the business model.

1. Give software away for free
2. Charge for support
3. Charge for custom development
   

You're giving the software away for free so you can't charge for a license. Charging for support means that when something breaks or your clients need help, you help them in exchange for a yearly or monthly fee. Unfortunately, by making your product a successful open source project, you destroy the value of your support contracts (see 1 and 3 in the first list). You say you want to charge for customization like a consultant? See number 2 in the above list. That project is going to the lowest bidder. Also, good luck making that scale.

What sucks here is that I like open source. And to make something sustainable, you have to be able to make money off of it. I don't know how to do that. The original author might, but he just spent two pages not telling us.

Related articles by Zemanta

• Dave Neary: Jerry Maguire on the future of the free software industry
• Is 2009 the Breakout Year for Open Source?
• Open Source Isn't A Business Model... Just Like Free Isn't A Business Model

The Best Programming Books of 2008

Image by eMaringolo via FlickrThere's a thread over at Stack Overflow asking for the Best Programming Books in 2008. I think I'm missing out because I've only read one of them: Programming Collective Intelligence: Building Smart Web 2.0 Applications.

It can be hard to keep up with what's been going on in the world of programming so I appreciate these lists. They help keep me up to date.

These are the books that are on my reading list, but only one of them is from 2008.

1. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series)
   


2. Real World Haskell
   


3. Smalltalk 80: The Language
   

Related articles by Zemanta

• Is Smalltalk Cool Again?
• Real World Haskell
• Stack Overflow: None of Us is as Dumb as All of Us

Unless you do something, listening is a waste of time

Image via WikipediaListening is hard. It's easier to ignore and rationalize. What's harder though is learning from those conversations and applying what you've learned. The real reason? People don't like change. It scares them.

Dave Winer's recent article - If you never listen you never learn - makes this point. He also offers an anecdote where they listened to one suggestion from one user "and company went from being in the brink of shutting down to gushing cash".

Yes, if you listen you can learn, but unless you're willing to do something about it, its a wasted effort.

If EMail is EFail, What's EFTW?

Image by Nils Geylen via Flickr"The underlying problem is that individual human beings don't scale." - Jeff Atwood

Not only is email inefficient, it leads to lost information. If I send you something by email, but Bob needs that info, how is he supposed to get it? In this day in age, if you can't get it through a Google search bar, it doesn't exist.

Now, I don't want to dump all of my company's information into the big G's index, and their appliances are a little pricey. So what do we do about internal data? Here are a couple of ideas I've come up with recently.

• Set up Wordpress and post time sensitive notices there.


• Set up a Mediawiki and use it to document EVERYTHING.


• When someone asks you a question, reply with the link, not the info.


• When you get information by email, put it in the wiki and reply with the new link


• When the volume of information starts to grow, set up Nutch, the open source search engine, or invest in a Google Mini.

This doesn't solve every problem. For instance, you still don't get a private Twitter or FriendFeed, but with a little creativity, I'm sure you can hack something together.

Final thought: Email is an expensive way to transfer information, and your time is to valuable.

Related articles by Zemanta

• Google updates search box

Follow my Tumblelog

I've started posting some of the random stuff I find online to a Tumlelog. You can find it at http://pfeff.tumblr.com.

The stuff I post there comes mostly from my collection of RSS feeds. Using the bookmarklet, its really to just post an interesting article with a quick thought. I have trouble keeping up with blogging, but RSS + Tumblr makes it really easy to post throughout the day.

Related articles by Zemanta

• The Tumblr-fication of Google Reader
• Is microblogging the ultimate test for an idea?

Code Formatting for Blogger

The code in my last post was formatted using Format My Source Code for Blogging.

Accessing the FriendFeed API from Rails

I was hacking around with the FriendFeed API last night, and after quite a bit of frustration I got ActiveResource to download the public and user feeds. The main problem I ran into was that ActiveResource assumes a very specific URL format, and I've never actually encountered an API that actually conforms to it.

This tutorial about ActiveResource and the YouTube API tells you how to manipulate the URL format. I didn't go nearly as far as they did though. To get ActiveResource to do what I needed it to do, I only needed to override one method:

class FriendFeed::User < FriendFeed::FriendFeedApi
  
  class << self
    def element_path(id, prefix_options = {}, query_options = nil)
      prefix_option, query_options = split_options(prefix_options) if query_options.nil?
      "/api/feed/user/#{id}"
    end
  end
  
end

This class wraps the user feed api. It makes a request to http://friendfeed.com/api/feed/user/{id} and converts the response to a ruby object when you make a call to FriendFeed::User.find(id).

The parent class, FriendFeed::FriendFeedApi, inherits from ActiveResource::Base and takes care of setting some defaults used across each of the API categories. For example, it sets the site variable on ActiveResource::Base to "http://friendfeed.com" and the format variable to :json.

What Do Search Engines Know that is NOT on the Internet?

When a company is as secretive as Apple, everyone loves to speculate about what they're going to do next. The latest rumor is that apple is about to jump into low-cost, ultra portable PCs (aka Netbooks). While this may or may not be true, something in one speculative article caught my eye.

That would seem to confirm findings that a search engine company shared with me on condition that I not reveal its name: The company spotted Web visits from an unannounced Apple product with a display somewhere between an iPhone and a MacBook. Is it the iPhone 3.0 or the NetMac 1.0?

Forget the stuff about the NetMac and the iPhone. What's interesting is the source: a "search engine company". They may be in the business of organizing the information ON the internet, but because of their position, they actually have MORE information than is on the internet. Given their vast search logs, what else do they know that none of us COULD know?

You Need to Know Marketing, Start with Seth Godin

I've been following Seth Godin for a while now. His book, Purple Cow, is a great read, and I just discovered that one of his earlier books, Unleashing the Ideavirus, is available online as a free eBook. You can download it here.

We geeks tend not to care much for marketing. I know I've my share of unpleasant run-ins, but instead of avoiding the business end, I've decided to learn more about it. Seth's books and his blog have turned out to be great resources.

VCBUILD : error Message: '9.00' violates enumeration constraint of '7.00 7,00 7.10 7,10 8.00 8,00'

I upgraded a Visual C++ project from Visual Studio 2005 to 2008 today, and my MSBuild script stopped working. It spat out the error message below and Google was no help.

VCBUILD : error Message:
'9.00' violates enumeration constraint of '7.00 7,00 7.10 7,10 8.00 8,00'

I made two changes that seemed to fix the problem:

1. Use the MSBuild.exe in \Windows\Microsoft.NET\Framework\v3.5\ instead of \Windows\Microsoft.NET\Framework\v3.xx.

2. Pass MSBuild the "/toolsversion:3.5" flag.

I hope someone out there finds this useful.

Check out this Good Video on Getting Real

Heard of Getting Real? Here's a video of Jason Fried (one of the authors) speaking at Business of Software. Check it out. If you have or haven't read the book its a good resource for familiarizing yourself with the concepts.



Thanks to Balsamiq for the pointer.

Also, I just found these videos over at Carsonified. I'll be checking them out this evening.

Why should I bother with multicore?

The September 1 issue of Fortune has an article on multicore processors (I don't think there's a link yet). Basically, it's telling the business folks what we've known for a while: the free lunch provided by Moore's law is over, and no one really knows how to program for these systems.

None of this is news to us. So why am I wasting your time bringing it up again? Well, I want to know who this is really going to affect. If we assume that most software will eventually be delivered over the web, the heavy lifting is going to be done on the server by something like a LAMP stack, and you're going to use JavaScript for the blinky lights. This is going to change how to approach concurrency, and how you take advantage of multicore, if you can.

On the server, a multicore chip is simply going to mean more thread in Apache or more Mongrels. How much to you really win by spawning multiple threads to handle a request though? That's just one more thread waiting for the database query to come back over the network. Likewise on the client. What are multiple threads going to get you other than more resources allocated to waiting on an Ajax call? I guess you could argue that it'll allow the UI to be more responsive, but we already know how to do that.

Before I get flamed, I want to mention that I am in fact aware that there are some areas that really do benefit from the increased horsepower. In particular: games, audio/video, large scale data processing. We already know that each of those can benefit from parallelism. What can your average web application do with those kinds of features though? Or rather, where should I be looking for application domains that take advantage of this new technology rather than simply have technology for technologies sake?

Code Sucks

Most code sucks. Mine included... especially mine... but other people's too. Despite the best of intentions and planning and playing with paper sketches and squiggly lines, all code eventually turns into an impenetrable mess.

You can follow all the rules about writing code and organizing modules and whatnot, but you end up in the same place. The problem is that we don't know the rules to writing software yet. The rules we do have a contradictory. We work with people that don't know the rules and/or don't know about them.

It drives me insane.

Sometimes you can fix parts of the code. Line by line, class by class, you can refactor and test as you go. Or, at least, that's what I thought. Sometimes there's just too much inertia. Your best code doesn't work in the presence of the existing code. Sometimes the code, the project, and the team are just too far gone.

It's a sinking ship... and there's no honor in going down with her. Man the lifeboats and wait to get picked up by another ship.

Its the Software, Stupid

I've had the opportunity to work with high end smartphones for almost my entire career. What I've learned is that the handset manufacturers like to sell based on hardware features while the carriers (ie Verizon and AT&T) like to run their own versions of the software. The result is a package that's never quite satisfying. In most cases you end with a hunk of plastic that, despite grand claims, can't do much more than make phone calls.

Last week, I dumped Verizon for AT&T so I could get an iPhone. Here in Columbus, Verizon has the best network, period. AT&T's coverage is rather spotty. I put up with it though because the iPhone is the first handset that get's the hardware/software package right (translation: the hardware is decent and the software actually works).

Verizon offered us a deal on the LG Voyager to try to get us to stay, but they completely miss the point. No one wants a phone because they look similar on a spec sheet. A smartphone is going to sink or swim based on the strength of its software. And until the rest of the market gets this and stops half-assing their software, the iPhone will win.

Naked Objects in WPF?

There is a rather niche architectural pattern called naked objects. In this pattern, you build your entire application as an abstract domain model. If you do MVC, this is like building the application using only the M. Your users will then interact with this model directly.

I call this a niche pattern because none of the major frameworks support it. What I want to explore though is how we can fake it in WPF.

If you use strict naked objects, you won't build a user interface. The framework will take care of it for you. Frankly, this kind of scares me. I only imagine the monstrous forms that will come out of this thing.

In WPF, you can define a template for arbitrary classes. What I'd like to try is to define a UI form by dropping domain objects and importing a resource that will act like a skin. That resource will have the templates that define how the properties of my objects will map to UI controls.

This is just a thought I've been kicking around though. One problem I haven't worked out is how to map events on the controls to method calls on my objects without making every single method a routed event handler. I'll have to see if there is a generically capture the events on some controller class and automatically re-map them to method calls.

Why would I want to do this? Well... I've got a couple 2000 line code-behind file's I've inherited that prove, yet again, that you can write spaghetti FORTRAN in any language.

A Crazy Idea about Dependency Injection

At the end of my post yesterday, I mentioned the term Dependency Injection. I can't go into too much detail because it's not a concept I've really been able to work with much... yet. My only real exposure is the Google Guice book.

That's not gonna stop me from diving right in though.

Basically, when you use DI, you never use the new operator which means you never explicitly allocate objects. In a modern programming language (where modern implies garbage collection), this give you quite a bit of flexibility to reconfigure your app without changing your business logic. You just configure which concrete classes are mapped to which interface. For instance, you can remap ICurrency from Dollar to Euro in one place.

What's struck me though is the implications this might have for C++. By taking 'new' out of the program logic, we should be able to abstract away most, if not all, of the manual memory management that is so painful.

Instead of allocating an instance object in the constructor and freeing it in the destructor, we inject an already allocated object into the constructor. It is now the DI container's job to allocate and deallocate that object. Finally, assuming that you have a good enough DI framework (is this like a smart enough compiler?), it should take care of that task for you. You just map types.

Am I crazy?

What's in your object?

In the ThoughtWorks Anthology, there's an essay by Jeff Bay called Object Calisthenics. Briefly, the essay lays out a set of rules for designing classes that are rather strict and quite different from what you'd normally use to guide your programming. If you do a quick Google, you'll see that this essay has received quite a bit of criticism in the blogosphere. Most people seem to say that the rules are too strict and just get in the way.

If you haven't read the essay, there's an overview here.

I'm applying these rules as much as I can in my day to day development, and I've noticed a few things. First, it's not kind toward legacy code bases. It is especially unkind toward WPF applications. WPF is built almost entirely on .NET properties and practically begs you to break encapsulation. Yuck... but I blame WPF rather than these rules.

Next, it's turned my code inside out. I'm used to grabbing a few objects, getting some data out of them, doing something to that data, and then passing that data to some other method. Usually this is so I can then return a new value. Since I'm not doing gets anymore, I have to send commands to those objects and then let them do some computation on behalf of the caller. It kinda reminds me of the message passing style you do in Erlang.

So what's this gotten me? For one, unit testing is easier. If you use get, you end up with an object that you then have to verify. This object will have state of its own which will likely have to be verified. This isn't a unit test anymore. It's an integration test. Instead, by sending messages, especially with mocks as parameters, you only have one layer of code to test.

Also, Dependency Injection become much more natural. But that's a topic for another post.

When is it time to move on?

No one stays with a company forever anymore. Especially in technology, it's normal to keep a job for a couple years and then move on to the next opportunity. Alex's article on IT turnover is the only answer I've seen to this question, but it's a good one.

Alex, though, addresses the question from management's perspective. What about the developer? All we know (again, from Alex) is that we eventually get the feeling that the job is just no longer for us. That's not real specific though, and probably leaves a lot of room for false positives. This frustration could have another source and a different way of dealing with it.

Personal Conflict

The actions of people working around you can be frustrating to the point of wanting to just walk out. Obviously, this is not the same thing as knowing that your time is up, and by walking out early you could miss out on big opportunities.

Solution: Identify the people that frustrate you the most. How are they impeding your contributions and your ability to learn? What can you do to ease the tensions or, failing that, side-step them?

Boredom

If you're bored, you're probably not learning, and you're not producing at your best.

Solution: Is there anything there that does interest you? Maybe a lateral move inside the company is in order. If not, it's time to go.

Don't get it

Maybe there's a problem with the system. Maybe it really is advanced and necessarily complex. Either way this leads to daily frustration.

Solution: If the system is broken, are your co-workers willing to help fix it, or would they rather simply live with it? If it's necessarily complex, this is a great opportunity. Find someone who can teach you the fundamentals of how and why it works. If no one can teach you, research it yourself. This will do more than just pad your resume, you'll be smarter for it.

Don't fit in

Sometimes your just meant for a different culture. The corporate man's probably not cut out for the startup life and vice versa.

Solution: If you can't or don't want to adapt, go find someplace that's a better fit.

Irrelevance

No matter how hard you work, or how persuasive your arguments, management and your co-workers just aren't receptive.

Solution: You need to find out why, so that if there really is a problem with your work, you can fix it. Otherwise, a new job won't fix anything. On the other hand, if you can't get a good answer out of them, there's nothing you can do to fix it.

Conclusion

It's true that eventually we'll need to move on and find another job. Just make sure it's for the right reasons. This is not a decision to be taken lightly. If you consider all of the points above (and come up with some of your own) and you still can't make the job work, then it's probably time to update the old resume.

CodeIgniter

I'm playing around with CodeIgniter, and I have to say that I like it. My web development experience is limited (I've done mostly SymbianOS), but so far it's been a lot easier to get into than Rails and Django. It doesn't seem to have the semantic overhead that I found in the other two frameworks.

The April fools jokes circulating the blogosphere seem kind of lame. We have CouchDb being rewritten in Java, and Google's Virgle. Neither of those are particularly entertaining. Tim's was pretty good though.

Don't demo development code

Apparently one of my coworkers is doing a big demo today. That's news to me. He's demoing the development version of the app. That's also news. I just committed some big changes. Oops....

Marketing for Geeks

This is a new area for me so what's below is mostly speculation and items on my todo list.

Writing code is easy for me, but deciding what to write has always been more challenging. I can't say I've found a solution, but I did find a technique in Tim Ferriss's The 4-Hour Work Week that I'm trying out. The basic idea is to market test your idea before investing and to fail until you succeed.

Step 1: Decide who your building it (whatever it is) for.
Step 2: Come up with a bunch of ideas for things they might be willing to pay for. Don't filter too much.
Step 3: Build a simple site saying what it is and what it does. Tell your visitors that it's still under development, but they can join the beta program by giving you their email address.
Step 4: Promote the site with Ad words.
Step 5: Build the product if you get a decent conversion rate, dump it otherwise.

See Tim's book for details.

I don't see why I couldn't test a new idea every couple weeks. Given enough practice, I don't see why I wouldn't start to get good at it.

Getting Along without a Database?

A thread on news.YC has got me thinking about some non-traditional web architectures. Iamelgringo asked pg if he was still handling persistence without a database and how it worked. The conversation then turned to transactional memories and cooperative multi-tasking (particularly Communicating Sequential Processes). This takes us toward an event driven model and away from the traditional one process or one thread per request model.

How would this work?

I admit I'm still a novice on web architectures having spent most of my time on mobile and now Windows clients, but I have a few ideas.

The paper Ralph linked to was my first exposure to CSP, and its rather interesting. Basically, you organize your program into a pipeline with each stage in a separate thread so that they can operate independently. This is the same technique a processor core uses to exploit parallelism without actually being parallel. As long as you can keep all of the stages active, you can increase your throughput without having to find a way to speed up the task itself.

What does this do for the web? Well, consider a request broken down into stages such as:

1. Receiving the request
2. Authorizing the user
3. Looking up the data
4. Rendering the template
5. Returning the response

The request can be modeled as a five stage pipeline which itself can be modeled with five CSP processes. You could of course just have the same number of threads processing requests in parallel, and this would work fine if you're using a traditional database because the database will handle concurrent access to the data for you. However, if you're using something other than a traditional database (which was the whole point of the thread), you'll have race conditions which will corrupt your data. The CSP model solves this problem since data is only accessed in stage 3 (that is, by a single process).

The question I'm still grappling with is what if you want to scale beyond five concurrent requests? Assuming you can't expand your pipeline into more stages, I can see partitioning the application so that different services are processed by different pipelines, or by replicating the pipeline. The second option eliminates the benefit of CSP by creating multiple processes that access the data in step three concurrently. The first option, on the other hand, can only be applied to completely independent services so it doesn't really help us to scale the original service.

So while CSP looks like it will help spread an application across multiple cores on a single machine, it still looks like we need concurrent access to data if we're going to scale a web application horizontally.

We know that simply storing objects in a flat file can work for a web application, and we know that providing a versioning mechanism can allow concurrent access to data. Perhaps we could simply serialize each object to disk on a file system that can be safely shared across machines? We would of course have to organize the files in a way that doesn't overwhelm the file system with too many files or files that are too large.