Welcome to the Qrimp Blog

I'm quite excited to be presenting Monday, March 31 at the Tulsa DNUG meeting. I'll be giving an introduction to some methodologies we can all use to accelerate application development using the INFORMATION_SCHEMA views.

Here's the item on the calendar at the Tulsa DNUG site.

We've added a new feature to our new Qrimp apps that will make it easier to modify your applications. Under the Design menu you will see two new menus, Design Mode ON and Design Mode OFF. Turning on Design Mode will show a next to headers and footers in your app. Hover over the icon to highlight the content contained within the header or footer. Click on the icon and you'll be taken directly to the header/footer that is being displayed. Edit it and return to the page and you will see your changes.

For users who have already signed up and do not have the Design Mode menus, select Add a Module under the Admin menu and add the Design Mode Menus ON/OFF module. You will then have access to the menus.

Occasionally we have been asked how Qrimp compares to Microsoft Sharepoint. I won't discuss costs here, but I will say that Qrimp is sold per user license for the Qrimp platform, not by the number of users within Active Directory. This can be a significant cost savings when only a portion of your organization will be using Qrimp.

Technicalities

First, Sharepoint is a very extensible system. It integrates with a lot of tools from Microsoft, including Windows Workflow Foundation. This is a nice capability, but these are heavily oriented toward developers. To customize Sharepoint capabilities, you'll need a license for Visual Studio.

Qrimp is designed to be fully extensible from the web browser. There is no need to buy Visual Studio or other tools from Microsoft unless you run Qrimp on your own servers, in which case you'll need SQL Server. You'll need SQL Server for Sharepoint as well.

From the front end, the interface is much easier to use. You can add new lists to Sharepoint from within the web interface, but it is fairly complicated. I recently asked a Sharepoint guru how difficult it is to teach business users how to extend the Sharepoint capabilities and he said it isn't very easy. We've taught users who previously didn't know what a database was how to use Qrimp. If a user can understand a spreadsheet, they can probably understand what Qrimp is.

The Database Architecture

The significant difference between Sharepoint and Qrimp is that accessing the Sharepoint database directly is almost universally forbidden. Microsoft does not support directly modifying the Sharepoint database. When I asked the aforementioned Sharepoint Guru what he thought about the issue, he said: "NEVER NEVER TOUCH THE DATABASE DIRECTLY!" A Sharepoint Thoughts post says:

Whatever you do, do NOT PERFORM DIRECT EDITS TO THE SHAREPOINT DATABASE.
* Do NOT manually update records
* Do NOT manually insert records
* Do NOT manually delete records
* Do NOT MODIFY SHAREPOINT DATA!!!

The reason is because the database architecture used to store the data within the Sharepoint system is much more complex than that revealed by the API to the developer. To access the data in the Sharepoint repository, you must go through the Sharepoint API. The API conceals the underlying data model from the end user and this data model could change with service packs.

Qrimp on the other hand builds a standard database architecture for your data. Tables are tables. If you view your table in grid view, that's what your table will look like if you accessed the database directly. If you update a record in your table with an SQL Query and then view that record from the web interface, the record will be updated. No harm done. One caveat is if you have versioning enabled on the table, the edit will not be stored, but your database will not be corrupt. Similarly, you can delete records or insert new records as well.

If you run Qrimp within your firewall, you can use bulk import tools to bring in as many records as you want into your Qrimp database and start using your system right away. There are some rules to how Qrimp stores information in the database to be aware of. Each table has an ID field that is an Integer Identity that is the Primary Key. The CreateDate and CreateId fields have special meaning for auditing. The rest is fair game.

Summary

The differences then, between Sharepoint and Qrimp is that Qrimp allows you to pay for only the users who use the system. Sharepoint is more extensible because you can use tools like WWF and Visual Studio to write any code you want -- but you have to code it. The final difference is that with Qrimp, your data is your data. You don't have to go through Qrimp to access it. If at some point in the future, you realize you need a custom process to access your Qrimp database and make changes and retrieve data, you can do that.

Qrimp is more flexible in this way. With Sharepoint, you are locked into using Sharepoint as the interface to your data. With Qrimp, you can pull your data out or access the existing Qrimp Database without any modification. Qrimp creates very nice standard data models for your data. Most DBA's will quickly recognize the models Qrimp builds for One-to-Many and Many-to-Many relationships.

If you have any questions about this, please don't hesitate to contact us.

Qrimp is a platform on demand. When I talk about a platform, I mean a system that allows you to modify the way it works. An enclosed system that contains all the moving parts to make your new solution operate. If you use the hosted system, our platform is there without you needing to purchase hardware or software other than the computers you already use to browse the Internet.

The platform is on-demand, because you can make it do what you need it to do when you need it done. You can manage any kind of information: Customers, Contacts, Task lists, Conference Schedules and anything that is particular to your business that the makers of Qrimp may have never even heard of.

We are excited to see how our customers use Qrimp and all the ideas we hear from people about what they could do with it.

Anything you can do with a database or spreadsheet you can do with Qrimp. The advantage of using Qrimp is that you bring all the tools needed to put an interface around that data into one location. You don't need Integrated Development Environments, Relational Database Management Tools, Code Editors, HTML Editors. You don't need to download anything, just use your browser.

To answer Adrian's question we must first determine who creates Open Source software, who uses it, what is its value and what will happen to all of those questions in a recession. So I'll start by answering the questions for the current economy and then address them in a recession.

Who creates Open Source Software?
There are mainly two types of organizations who write open source software: Individuals who want to solve a problem and companies who want to earn consulting fees or attack the business model of a competitor. Currently, we have a good industry for IT people. A lot of them write code on business hours. Open Office is supported by Sun to help fight Microsoft. Sun has a team of over 100 developers working on a product that generates no revenue and the justification is that it hurts a competitor, both in sales of Microsoft Office and by enabling users of Linux to have an Office Suite.

The problem with this model is that it is difficult to quantify the financial benefit. In a recession, the bottom line matters most and I suspect companies will abandon these models. In times of recession, employee productivity is important and that productivity must directly affect the bottom-line in a measurable way or the employees are laid off. Those laid-off employees may have more free time to work on Open Source projects to keep their resume fresh, but they may be too busy looking for a job. I suspect it will be the bright ones who have saved money that will find Open Source more easy to fit into their schedule and it may be an avenue for independent contracting and consulting sales. The rest of the laid off crowd may not have the technical capabilities to product good software, so the quality of open source may decline while the quantity rises. This could hurt customers of Open Source software and prompt them to abandon it, because of the Market for Lemons.

Who Uses Open Source Software?
The primary audience for open source software is companies and individuals on a budget. In times of recession there will be more of these so the market for Open Source software will grow. With this additional demand, the supply will shrink. Not the supply of the bits, but the supply of developer time to meet the needs of the growing customer base. This may allow free software models to begin charging for their work and develop a paid software product. It will be the best of breed who go on to create companies around these innovative products, but the best Open source products may convert to commercial licenses.

Larger companies in times of recession will take fewer risks and this could hurt the market for open source software. Open Source is already more risky than commercially produced software and this keeps many away now. Those with the ability to accurately determine the quality of software may decline in times of recession and further limit the market.

What is the Value of open source software
First, we must acknowledge that open source software is not free. Many times it comes with bugs, it is not of the highest quality, the user base is smaller and the technical skills required to use it are higher requiring a bigger investment in education up front. The real value of Open Source software is the innovation and competition it brings to a market with huge barriers to entry. Small groups of coders working independently and in their free time can chip away at a large market, but it takes a very long time to make any headway or generate the kind of revenue that can support full-time concentration on a project. This amount of time is often longer than a recession. A lot of the major open source projects now were around during the dot-com boom and survived.

I think the market for Open Source products at the corporate level will shrink due to risk aversion, but grow among individuals because there are fewer of them working and they'll be spending less on technology. This could be good for Open Source because more people with technical skills will work on it. The problem this raises is that the high quality programmers are the last to get laid off and the low quality programmers only code for money.

Is Open Source recession proof?

If this question means, "Will open source go away in a recession?" The answer is no, there will still be plenty of people dedicating time to open source. Corporate sponsored open source projects will likely decline. Individually created projects may increase, though the quality will diminish.

The bottom-line is that recessions are bad. Open source will be hurt, but it will not go away.

All the fuss about Data Portability in the news lately is a much bigger issue than names and email addresses. Data Portability is about making your information easier for disparate systems to access both within and beyond your control.

One of my clients recently needed access to information from multiple vendors. They were in the business of reselling similar products and helping users find the best price. Part of the job was pulling the pricing and product information into a vast database that we could search through to find the exact match for the customers' needs and help them decide which one to purchase.

After contacting the vendors, there were about 10 of them, the conversations were all pretty much the same -- either it was too complicated for them to provide the data or they didn't have it outside their proprietary systems. The smoothest process in most cases involved someone from Company A calling someone from Company B and asking them what the current values were.

Such a process is horribly inefficient and prone to compounded data entry mistakes. Had Company B simply provided the data in XML, CSV, or some other sort of flat file, the process would have been very simple. But they didn't, in most cases, because it isn't simple to do that. Many systems might have the ability to export data, but how do you automate the process and how do you make that exported data available to users securely over the web?

Sharing data should be simple and painless. With Qrimp it's as simple as modifying the URL. For example, on the Qrimp demo site, you can view a list of fuel economy by vehicle in HTML or fuel economy in XML or CSV that you can easily import into your custom application. You can even create custom formats for RSS Feed Syndication, JSON and more.

If you have security enabled on your information and don't want just anyone looking at it, you can create a username and password. The organization with which you want to share information then makes two requests. The first passes the username and password and receives a customer user token that it uses to make subsequent requests.

Qrimp didn't exist while I was working for those clients, but if it had, they would have easily saved tens of thousands of dollars in development costs. The companies with the products would have saved money as well and increased exposure for their products much quicker. In this industry, time is money.

This was my motivation for building Qrimp. Not only will it save companies thousands, even millions of dollars, but it will help them bring these products to market much faster.

Today I thought, "If Qrimp is such an awesome platform, surely it'll be able to integrate with Facebook." So I grabbed Tara, because she has a Facebook account and we set off to create a Facebook app with Qrimp. After wading through the documentation, here's Tara's Facebook Qrimp App, which took about 5 minutes to build after we found Jonathan's post on Facebook Application Basics.

I won't get into the details of how to do it here, but we posted a Howto: Build a Facebook App from Qrimp topic over at the Qrimp Developer Network. Go there for the details.

The Experience

First of all, how many people know what a Callback URL is? What percentage of those people are not programmers? Exactly. Building Facebook apps could be a whole lot easier. They need to make it easier. I suppose it's easy enough if thousands of apps have already been built for it, but as I've said before, Facebook is limiting its potential with such a difficult to use system. As Paul Graham says:

It's worth trying very, very hard to make technology easy to use. Hackers are so used to computers that they have no idea how horrifying software seems to normal people. ... When you work on making technology easier to use, you're riding that curve up instead of down. A 10% improvement in ease of use doesn't just increase your sales 10%. It's more likely to double your sales.

I don't even know why I'm offering this advice, because I have no respect for Facebook, especially if Zuckerberg is as dishonest as they say, but the plaintiffs do look kinda like a-holes. I think in general, social networks are the new opiate of the people.

The proof is in the numbers

At the Web 2.0 Summit, Zuckerberg said, "We have 6,000 applications and 100,000 developers." That's over 16 developers on average, per application. With a ratio like that, the developer pool will be quickly exhausted. For web platforms to succeed, we'll need to see that ratio come down -- way down.

I don't mean to be overly critical of Facebook and other social applications. I just don't see the value in them. Perhaps it is my introverted nature. Perhaps it is my focus on earning time over wasting time, a topic I might get into more detail on later. Qrimp is a time earner, so it might not be a good idea to integrate it with a time waster like Facebook, but my goal was to test the integration of Qrimp with an arbitrary system over which I have no control -- Facebook fit the bill.

I also recognize that integrating applications with Facebook and other systems can be much deeper than our proof of concept, but doing this with Facebook is not a priority for the Qrimp team right now. Many of our users may want to go further down that road and I leave it to you or them to do it. If you do, I would be vainly interested in seeing what you've done, so let Tara know and she can log into Facebook and check it out.

In all fairness, I thought it would be more difficult than it was. I also learned more about Facebook in the process -- this is was the most I've ever used it. I see a lot of room for Facebook to improve their "platform." I actually don't think it is a platform at all. I see it as an API. A platform lets you build your own applications. Facebook lets you integrate your application with Facebook. Mark Andreessen says Facebook is a Level II Platform. Mr. Andreessen breaks the term down into multiple levels, but Wikipedia's definition of Platform wouldn't include Facebook. I think Mark was being kind to those who call themselves platforms, but really aren't. I might be in the minority on this, sure, but I sometimes think that marketing has more influence than sense. It might just be a lack of sense that gives marketing its power.

A lot of people are talking about The Web as a Platform and I think the basic idea missing from these conversations is being able to program the web from the web itself.

If we are to succeed in our quest, we are going to have to get everyone on the same page, using standard technologies with simple interfaces. Web Services is too complicated. API's are particular to every application. It's too much to learn and only a small percentage of the world has the experience and time to do so. Not only that, but to take advantage of these APIs, you have to have your own hardware and software infrastructure. How many Facebook app companies have run out of hardware? The infrastructure costs for a scalable environment to support applications like these is beyond the range of the majority. Facebook is limiting the potential of its platform by requiring the Application developers to provide their own servers.

REST, Web Service, API, SOA... 99% of the world has no idea what those words mean, but 100% of them will benefit from the free flow of information those ideas enable. While I agree a lot of those technologies make it easy for programmers to integrate systems, they only make it easy for programmers to integrate systems. What about all the non-programmers? What about all the people without 4 year degrees in computer science? How are they going to contribute to the programmable web and how are they going to build custom systems to help them be more productive?

There are not enough programmers to solve all the problems that currently require programming. We need to bring our skills -- not just the applications we build -- to a larger population of individuals.

Today, most users must be content to wait for the programmers to bring them a solution. I've been working on the web for quite a while now and many people have come to me with a great idea to do something or another. A lot of them are really great ideas -- some of them aren't, but I am forced to think of ideas with respect to cost benefit analysis. Is what you want to do on the web going to be beneficial enough to the world that you can recover the costs of development? Usually the answer is no, which is unfortunate, because the applications would benefit a great number of individuals -- just not enough to pay for the development.

We must lower the barriers to entry for information systems. This is a scary thought for a lot of programmers, because some believe we will be working ourselves out of a job. I prefer to believe that we will be making our jobs more enjoyable. We'll take off our shoulders the constant attention to user requests by enabling them to do what they usually relied on us to do: changing field types, altering functionality, modifying the look and feel.

The funny thing about the end user is that the developer can build a tremendously complex system that has all the functionality they need and the most frequent complaints will be nit-picky. "See the big picture!" I think to myself. With Qrimp I just say, "Okay, you can change it. Check this out." I love the look of "Wow!" on a face.

The point I am not so eloquently making is that as developers we must begin to relinquish some control of our systems to the end users. We must allow them to modify those systems to their personal tastes, look at MySpace as an example of this. MySpace allows users to modify the look and feel of their pages and the end result is nearly always horrible, but the desire to customize is evident. 90% of MySpace pages look totally different and yet at the same time, beautiful to the owner. We need to take this capability to the next level and enable the customization of functionality, not only the look and feel. Imagine if MySpace let you determine how users' pages looked to you.

Every user of your system will have a different idea about how it should behave. I can't count the number of times I've visited a web page with a list of the top movies of the year and wanted to click the name and visit IMDB. Doesn't everyone want to do that? Oh yeah, some might want to go to NetFlix or Greencine. We need to enable our users to change things like this within their own applications. Maybe when I create a new something or other, I want to specify the next page to display. Maybe a list of all the items, maybe the detail view for the particular item. As a user, I should have that level of control over the systems I use.

Open Source has a huge install base of software, operating systems, databases, JavaScript libraries, graphics and more, but enhancing those Open Source products is beyond the capabilities of the majority of its customers. The biggest problem with Open Source -- is the source.

At Qrimp, we use Open Source products in our software. We use Icons from YellowIcon, JavaScript from in the Yahoo UI Library and AjaxRequest, we love FireFox, and we've even used SharpDevelop once or twice, so we recognize the benefits Open Source brings to all of us, but the product, that is, the Open Source, has a limited audience.

What the audience wants is not Open Source. The audience wants features, products, and software. Most users of Open Source software couldn't care less about the Source Code and even if they did, which I do, they don't have the time or the experience to enhance it. How many of those who use Firefox have ever written a line of code for it? How many of those who use Open Office dive into fix a bug or improve the usability? We haven't. We just don't have time. It's too difficult.

The reason it is too difficult is that there are simply too many ways to write source code. There are Open Source products in PHP, Java, Python, .NET, C++, Ruby, JavaScript... there are too many to mention. The source code for those projects is kept in CVS, Source Safe, BitKeeper, Subversion... How many more? And platforms? Windows, Linux, Mac... How can anyone keep track of it all?

We need to get on the same page. All of these projects, at least the projects focused on web applications all use a standard set of technologies: HTML, JavaScript, CSS, and at the lowest level SQL. These four components are required for nearly any web-based system and developers have to know them whether they are building systems in Java, Perl, PHP, or .NET. For the most part, developers have to know these 4 core technologies to build any successful web system. These 4 technologies are the lowest common denominator of web development -- regardless of platform, development environment, programming language, or browser.

If we can limit the level of experience needed to enhance and distribute Open Source software to this lowest common denominator, we can greatly increase not only the audience of potential customers, but also the field of developers and users who can contribute ideas, enhancements, and labor to the movement.

Democracy and choice are good. We should all be allowed to develop in the language of our choice. Some of us speak multiple languages and some of us program in multiple languages. The diversity leads to a rich and engaging world and is awesome, but it might not be so productive. It takes time to translate from one language to another. It takes time to understand someone else's code, install development environments, make changes, recompile, and integrate your code with the core. If we were all to contribute to every piece of open source that benefits our lives, our computers would be bogged down with compilers, source code repositories, and databases and our brains would be full of algorithms, syntaxes, and constructs from countless programming languages. It's just too much. We are slowing ourselves down.

The way to fix the problems of Open Source is to enable the enhancement of Open Source projects without requiring those who wish to contribute to understand the source. We can't expect everyone to learn the language the product was developed in and we can't expect everyone to understand the code itself. Code is complex.

One of the worst jobs developers are thrown into is supporting someone else's code. Imagine a writer being asked to finish someone else's book or an entrepreneur finishing someone else's company. It's boring, monotonous and nearly impossible to get passionate about it. We need our own projects, we need the ability to develop our own solutions, all we need is a common language to communicate with everyone else who might be able to help us or be helped by the projects so dear to us and everyone who uses them.

According to the W3's browser stats as of the end of 2007, about a third of internet users are still using IE6.

In the web design world, it is well-known that IE6 does not meet certain standards .

We would like to recommend to Qrimp users that they will have a better visual experience if they use a browser above IE6. Does anyone know if there are any reasons that anyone should not update their browser?

That's it - 'nuff said!