[kwlug-disc] Fw: Continued: OpenSource Me!]

Raul Suarez rarsa at yahoo.com
Thu Jan 8 22:36:17 EST 2009


I sent the attached message before but for some reason other emails I sent around the same time were never received. Here it is in case it never made it to the mailing list

 Raul Suarez


Technology consultant
Software, Hardware and Practices
_________________
http://rarsa.blogspot.com/ 
An eclectic collection of random thoughts



----- Forwarded Message ----
From: Raul Suarez <rarsa at yahoo.com>
To: KWLUG discussion <kwlug-disc at kwlug.org>
Sent: Monday, December 22, 2008 9:49:02 PM
Subject: Re: [kwlug-disc] Continued: OpenSource Me!]

Finally on holidays and with some time to respond to this post. I will try to be direct and to the point although it may prove difficult as I have a lot of beefs with what's been said (Actually after some refinement I may turn this response into a blog entry):

1. Why? What? How?
I can sense a lot of confusion in this thread. It started with a need that became a "probably I can make a buck with this" that became a what will be gained if I OSS this that degenerated into what platform to use and then to what kind of application I will develop.

So I will try to respond to each of those issues. For some of them I am an expert, for some I just have an opinion like everyone else.

2. There is a need:
The main purpose of software development is to fill a need. If you are a software shop or software professional you fill the need for someone else and software development expertise is your asset, if you have the need then someone else - whether internal or outsourced - is going to do the development and business acumen is your asset. Don't try to mix both unless you are an expert at both.

3. The "not invented here" syndrome:
Your initial post made me think that you hadn't look hard enough to the existing CRM offerings or that you wanted something different than a CRM. As I see it a CRM is a single purpose tool but should have hooks to other purpose specific applications. If you want to put it all on the CRM you'll end up biting more than you can chew. I'd advise looking again at CRMs with third party integration in mind. regarding CRMs I've seen too many wheels being invented over and over.


4. The buy, addapt, build mantra:
Let's say that although CRMs have been around for decades, you have a totally novel way of handling customers that's better than anything we've seen... Don't write software, write a book, it'll be a best seller. (this is not a joke, keep reading)
No, really. According to said mantra, most likelly what you need is already out there. If its not out there there may be something that is close enough that can be addapted. If that fails, then I agree, build, but really write a book about your method.

In some cases I've had to spend months evaluating software options before advising to buy, addapt or build. It's usually worth the time.

5. The OSS question
Under OSS, sofware is not perceived as a product, but as a means to an end. The real product is the business acumen required to create said software. If you get into the CRM software business, you won't be selling the software, but the CRM practice that led to having a unique software. This is, you will be in the CRM consulting business. Even if your competition gets hold of the software, they will lack your secret ingredient to make it work the way it should. Even in the proprietary software world, you'll see that frequently companies buy great software but fail to use it to its potential because they neglect using the professional services provided by the vendor. So trust me, in this regard there is no difference. The difference is that with OSS, other people will be able to build on your fundations or take it in a different direction that will suit their needs. Your challenge will be addapting and improving your method with all the ideas that you may
receive.

6. The platform question:
OK, lets say that you have a novel method, that you understand that software is not a product and that the sofware will be close to useless without understanding how to use it. You've already decided to write it and ofer it as an OSS (or proprietary).

Here is where the distinction between business acumen and development acumen is paramount. If you haven't spent years designing and writing software, don't expect that picking up a platform and handing it to a mediocre developer will be successfull. You will have to pay decently for someone with enough SW development acumen as to be able to recommend a platform and a sound architecture. This is where building good software gets expensive. A piece of advice: C and C++ are good platforms for drivers, libraries, tools and algorithms not very good for the front end of a business application. A good architecture will allow you to select the best platform for each of the tiers allowing you to be able to have multiple front ends to your business logic.

Regarding the question about abstracting the Database access. That's an example of why you should deal with an experienced developer. This shouldn't even be a question. Only very novice business application developers would not separate the Database tier well enough as to make it interchangeable.

Please note that good software is expensive to
build, and substandard software is very expensive to maintain. Also note that you build once, but maintain for ever.

7. Who will the application support? (windows, linux, larger clients, smaller clients)
To be really successful you should grow it organically. Start by supporting your own needs. First the most basic. Use it, perfect it and then add to it. If you get a decent development team they'll not be affraid of refactoring and addapting to change. 

Start with a good vision, but don't translate it into specific requirements until you get there. You could end up with a magnificent specification that is unworkable or outdated by implementation time. On the other hand, if you get to a point where you have a product that meets your needs, but you don't see interest from other parties, you didn't waste time or money. All the money was well spent.

8. As a business person you should already know that the cost of building the software is spare change compared to the cost of marketing it. Building in-house software has different requirements than Open sourcing it, which are different than shrink wrapping it.
- With in-house software you can get away with an efficient but simple looking interface, no branding, simple (or no) help system. 
- With open source you may need to follow and publish coding standards, brand the product, maintain a web presence, etc.
- With shrink wrapped software, don't even think going out with a good creative team, UI expert advice, Full branding, legal costs and of course marketing

Finally as a shameless plug and disclaimer. In the past I've done consulting on the side providing advice and/or hands on development under very similar circumnstances.

Raul Suarez


Technology consultant
Software, Hardware and Practices
_________________
http://rarsa.blogspot.com/ 
An eclectic collection of random thoughts


      __________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now at
http://ca.toolbar.yahoo.com.



      __________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr! 

http://www.flickr.com/gift/



More information about the kwlug-disc_kwlug.org mailing list