Getting Started

How to get started in property investing with no money and a low income salary.

Get your FREE e-book now

Bad Tenants

11 Ways to avoid a bad tenant or worse a squatter.

Get your free e-book now

FREE DOCS

Need real estate FREE documents?

Legal documents, analysis tools, application forms, NCA forms and more.

Click here to get documents FREE

Syndicate

Sean Wheller
Advertisement
Jul 17 2006
Whole Open Source Products
Monday, 17 July 2006

If open source projects are to mature they will need documentation that is at least equal to proprietary projects. The problem, at present, is that open source is still stuck in the 'enthusiasts mode'. Yes, it is trying hard to change, but I don't think the traction will take place until thinking turns from a strong source code focus to a more balanced look at developing 'whole products'.

Most open source projects have a very immature 'go-to-market' strategy, if any. While documentation is part of the research and development phase, it is a key component of a 'whole-product' and therefore instrumental in improving a projects ability to 'go-to-market'. Look around. When last did you see an open source salesman? When last did you see a business person that understands a techie?

Bernard Golden, author of the book "Succeeding with Open Source" explains it well, although with a different lense. Golden indicates that one of the best ways to judge the maturity of an open source product is the level of documentation. Naturally, documentation does not stand alone, community activity is also critical, but documentation wins points in a competitive analysis.

From my experience, community chats on IRC and forums don't cut the cake, even with casual users. Yes Google is great, but how much time do you think a person wants to spend searching, reading archives and verifying the integrity of what is often badly written disjointed statements interjected with off-topic conversation. Official documentation is always the preferred source. Users mostly refer outside of this channel when they cannot find the answer in the documentation. As for community, it's far to blunt and will not hesitate to remind you to 'RTFM', or just ignore you. I know, I am as guilty of doing this as anyone else. Corporates cannot afford to rest their millions on a 'help you if we feel like' model. So, in corporate environments the problem is just amplified.

Considering the community nature of open source, people come and people go, providing documentation is important for user stability. Programmers like to say, "The only thing that remains is the code." This is one way of viewing it, but in a business world, the code is useless if nobody knows how to service or use the application it defines. Business wants software, not for the code, but for the service it provides when servicable. What they want to avoid is critical events. Software that results in too many of those, does not last long. I don't care if it is proprietary or open source.

If open source projects and their community are to solve problems once and then make it cost-effective to solve them the next time, they must be able  repeat the process cheaply. Only documentation can do this and must therefore be a larger part of the whole open source product.

Comments
Add NewSearchRSS
Write comment
Name:
Website:
Title:
UBBCode:
[b] [i] [u] [url] [quote] [code] [img] 
 
 
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch:
:(:shock::X:side::):P:unsure::woohoo::huh::whistle:;):s
:!::?::idea::arrow:
 
Security Image
Please input the anti-spam code that you can read in the image.

Copyright (C) 2007 Alain Georgette / Copyright (C) 2006 Frantisek Hliva. All rights reserved.





Digg!Reddit!Del.icio.us!Google!Live!Facebook!Slashdot!Netscape!Technorati!StumbleUpon!Newsvine!Furl!Yahoo!Ma.gnolia!Free social bookmarking plugins and extensions for Joomla! websites!
 
< Prev   Next >