Let me come straight to the point. How many times have you gone through a FOSS based tool or an API and have cried in agony about the lack of documentation. If the tool/API is flourishing, then you would atleast find a statement saying "Documentation for this section has not yet been entered" or something equivalent, else nothing at all. You pray to Google to give you some information and if lucky, you may end up with mailing list archives or a half written geekey document which you could have well avoided reading.
The outsourced testing services market is about $4.6bil, of which $3.0bil is sent offshore. Well, this is true and what is also true is the raise in enterprises adopting FOSS products. And when they sell services around it, they mean that the product has gone through some validation and is of some quality ready for usage (either enterprise deployment or small scale). Productizing definitely constitutes good documentation, however have we thought about making documentation one of the core aspects of productizing a software ? or documentation as a business provider in itself as is testing ?
For example, monodoc is an amazing tool which encourages developers to contribute as and when they meddle around with the API. Why can't there be wide speard drive to motivate all IT related guys to contribute to documentation ? I understand the job can get a little boring but tools like monodoc are really the way to go.
Documentation of FOSS products has so far been a community effort which is good. And when enterprises take up a software, they do provide good docs, but can't the process be a business in itself or is it such a trvial activity ? However we all realize that it sure has a significant impact on its users.
Subscribe to:
Post Comments (Atom)
1 comments:
That what differentiates a software, a software system and a software system product.
Generally a developer can write 500 line of working monkey code a day. But it drops down to just 30 lines/day if asked to rigourously document the code. ....And yes by that I mean the developer has to document his code not a documentation team which proof reads the code and churn out docs according to its understanding.
The above methodology is followed in most CMM-5 companies including Microsoft. The problem with FOSS are that their developers are total geeks and they find documentation trivial. And most FOSS products are never meant to be of any commercial usage so they dont see the need to document the code which they wrote for themselves.
monodoc is Linux incarnation of C#.NET which itself was shamelessly copied from Java Docs. But as always tools like C#, Java and Mono are generally used to implement Business logic and such projects are rarely open source. And believe me when I said 30 lines/day/developer ...i really meant it... thats why companies have projects that run for 4 years with 300 developers!!
tldb is again a community effort but the developer of the code never documents his own code... the community does... resulting in crappy docs.
If Linus thought that his OS would create a revolution he would have documented his code properly and we would still be using kernel 1.0 :)
Post a Comment