Open Source 1997 vs. Open Source 2007

I just got off the phone with Jack Loftus, of TechTarget, and he was asking me some very pointed and insightful questions on open source business models. I’m sure he felt my enthusiasm on the subject as I highlighted some of the antiquated theories of what makes a good Open Source company and good Open Source business model. Mind you, I’m not interested in debating over the “One True Definition of Open Source™”. I’ll leave that to the fanboys. My conversation with Jack got me really pumped so I decided to write it down some additional thoughts in more detail. (Jack’s interview covered way more then that, so I don’t think I am ‘scooping’ his story in any way!)

Let me break out the real differences between the types of Open Source projects out there, and I will let you decide what kind of project you prefer.

Open Source 1997 — software available for the public domain generally built by users trying to solve a problem they have and offer up their solution in case someone else can use it. This is great, but it inadvertedly created two fundamental problems. One, in order to adopt the solution, you’d have to get your hands quite dirty. For example… step 1: untar the source step 2: ./configure step 3: make && make install. The software may not have designed by an engineer with an eye for ease of use, adoption, and reuse. In other words, it was not ‘productized’. This is OK, but it makes the tool generally awkward to adopt. The second problem is that it’s incomplete. It solved one users problem, and maybe a class of users can get mileage out of it. But it was designed as a band aid, not as an innovative, well thought out, BETTER solution to the problem. Maybe it copied old expensive software in the market place and made it a cheap alternative. Maybe it introduced a new approach, but left the barrier of adoption too high because, after all, who doesnt know how to compile stuff, right? Regardless, the end result is a hard to use, incomplete tool. So, two things now happen. Either it muddles its way out there in the ether, or a commercial company comes up behind it to commoditize it. They do this by persisting the idea that its hard to use and incomplete. Why? Because they sell services to address that problem. They are more then happy to perpetuate this hard to use model, and foster a dependency on themselves. Ultimately the user still gets that cheaper solution then the big proprietary option. But its definitely not better.

This is the common mentality of lackluster open source proprietors out there. They earn a bad rep for the company and put misguided ammunition in the hands of people who like to throw FUD on Open Source projects all around. It does however, give Dave Rosenberg amusing fodder to tear down those perceptions rather publicly in his blog

Here’s what’s really needed…

Open Source 2007 — innovative, easy to adopt software solutions, purpose-built for solving problems of scale. Scale being both the market size and the customer size. Designed for easy deployment, usage, and extensibilty – these software projects ultimately will be longer lived and more relevant at the end of the day. But they’re not incomplete and hard to use, so how can you make money? I get back to that little word at the beginning – scale. In open source, you design your projects so that 99.9% of your users are satisfied with what you give them and they are able to make their own judgement on whether the product meets their need. No sales pressure, no POC’s, no time-bombed trials. They may choose to join the community and give back, but they are essentially using the software for free. Most educated consumers of open source technology know that it’s not about the cost of the software, it’s about where the value is. The portion of users that have a larger scale problem and typically have a couple layers of management involved can get the front office, upstream folks to pay a modest fee. This is how successful companies like Jaspersoft and a number of others have been doing it for some time. They provide very flexible, standard reports for end users, and charge once the higher ups want more complex reporting authoring. This is how we do it, complete for the end user – but once senior management wants to enforce more complex management rules — we ask them to pay, and they usually do, happily. After all, they were budgeting to have to pay non-open source competitors anyway. The reason they’re happy to pay is because they know that there has to be a trade between the consumer and the provider in order for the relationship to really work. In mission critical computing environments, it has to work. Period.

BTW: As an aside, in case you haven’t been out on our forums lately, we’re serious about our respect for Jasper. We just entered an agreement two weeks ago and started a project with them. Because we’re both oriented to this type of flexibility and value creation, we’re about halfway through our phase 1 of integrating JasperReports into our Open Source summer release. We should have the first result for community review in about a week. Now that’s just cool!

If you like this post then please consider subscribing to our RSS feed. You can also subscribe by email and have new articles sent directly to your inbox.