http://pcquest.ciol.com/content/editorscolumn/techetete/2010/110010801.asp
I think we are losing the value of Open Source. The core objective of Open Source has been to let people learn the internals of a software application with the help of source code, and improve it further so that everyone benefits.
[...]
Let's understand this with my favorite example-Anaconda installer for RedHat based Linux distros. Anaconda is a fantastic piece of software, but it lacks documentation. So to modify it, you have to be a reverse engineer, and not a software developer. Therefore, contributing to its further development is difficult.
True!!! Agree with You Sankarshan.
On Tue, Jun 22, 2010 at 12:37 PM, "sankarshan (সঙ্কর্ষণ)" < foss.mailinglists@gmail.com> wrote:
< http://pcquest.ciol.com/content/editorscolumn/techetete/2010/110010801.asp
I think we are losing the value of Open Source. The core objective of Open Source has been to let people learn the internals of a software application with the help of source code, and improve it further so that everyone benefits.
[...]
Let's understand this with my favorite example-Anaconda installer for RedHat based Linux distros. Anaconda is a fantastic piece of software, but it lacks documentation. So to modify it, you have to be a reverse engineer, and not a software developer. Therefore, contributing to its further development is difficult.
-- sankarshan mukhopadhyay http://sankarshan.randomink.org/blog/
india mailing list india@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/india
On Tue, Jun 22, 2010 at 12:37 PM, "sankarshan (সঙ্কর্ষণ)" foss.mailinglists@gmail.com wrote:
http://pcquest.ciol.com/content/editorscolumn/techetete/2010/110010801.asp
I think we are losing the value of Open Source. The core objective of Open Source has been to let people learn the internals of a software application with the help of source code, and improve it further so that everyone benefits.
[...]
Let's understand this with my favorite example-Anaconda installer for RedHat based Linux distros. Anaconda is a fantastic piece of software, but it lacks documentation. So to modify it, you have to be a reverse engineer, and not a software developer. Therefore, contributing to its further development is difficult.
"Reverse engineering", as defined by the author is a part of most development process. It's annoying, yes, but most projects really do not have the level of documentation the author wishes for. The reasons for this are usually, that projects do not have enough people doing documentation or even capable of doing documentation, since optimum documentation of code is an art that is rarely practiced.
However that being said, in the Free/Open Source world, especially for large projects, the code often speaks for itself (via sane/appropriate naming of functions, variables, files, modules, etc). The reason for itself is twofold. (a) since the code is accessible to all, developers often are conscious of the fact that they are often measured in terms of their code by their peers and prospective employers, and thus maintain a reasonable level of control on the quality, sanity and readability of the code (b) most projects (unless it is a one person affair) have a minimal level of review process which ensures that the code which goes through into the main repository makes sense.
I fear that what the author is experiencing (and even I feel this sometimes) is difficulty coping with software which is getting bigger and bigger and starting to handle more and more corner cases. This is especially true for already deployed, user-facing software like anaconda. When this type of software grows (in terms of userbase), along with the the usual complexity and functionality increase, there is a lot of band-aiding and duct-taping to ensure that it works well for all possible scenarios. This reduces the readability of the code to some extent, and trying to handle this with documentation will probably not work well.
I took a cursory glance at the Anaconda code, and while it is a large project, it does not seem _that_ difficult to me. But again, the author talks of beginner programmers, and I agree that for "opportunistic" programmers, it is really difficult to contribute more than trivial patches to a project like Anaconda or Nautilus unless a pretty large chunk of time is invested to figure out the code. But this is to be expected of any software (or anything that increases in complexity), and FOSS is not an exception. And it is for these scenarios, that projects/concepts like gnome-love and openhatch become important.
Thanks, Sayamindu
PS: On a slightly related context, a few years back, there was a leak of the Windows source code and an analysis of the code was posted. You can see the analysis at http://www.kuro5hin.org/story/2004/2/15/71552/7795 to see how life is on the other side of the fence (the analysis contains only comments, and no actual source code, so it should be safe to see - but IANAL and you have been warned ;-)
On Tue, Jun 22, 2010 at 12:37 PM, "sankarshan (সঙ্কর্ষণ)" foss.mailinglists@gmail.com wrote:
http://pcquest.ciol.com/content/editorscolumn/techetete/2010/110010801.asp
Empty article that complains about how people who spend all their free time doing FOSS are not doing enough, since they're not building documentation so that people will understand stuff without reading the code. The article would have been more fun to read if he would have talked about 'leveraging', 'synergy' and 'collaboration'.
You can never _really_ understand stuff without reading code.
I think we are losing the value of Open Source. The core objective of Open Source has been to let people learn the internals of a software application with the help of source code, and improve it further so that everyone benefits.
A very limited view of what FOSS is. People do not write FOSS to _just_ so that others can read and understand. It is one of the by-products. The intention of writing stuff in most cases is the need to have something working. The sharing is there because I hope that it will improve it.
Let's understand this with my favorite example-Anaconda installer for RedHat based Linux distros. Anaconda is a fantastic piece of software, but it lacks documentation. So to modify it, you have to be a reverse engineer, and not a software developer. Therefore, contributing to its further development is difficult.
A very wrong use of the word 'reverse engineering'. While it is a little difficult to understand the layout of a program without its documentation, it is a really poor excuse if someone puts that up as the reason for not contributing to a project. Reverse engineering is when you have to work with streams of binary information (code or data) and try to make sense out of it.
The article is really quite pointless. It has only superficial complaints; no real insight at all.
Hi,
On 06/22/2010 12:37 PM, "sankarshan (সঙ্কর্ষণ)" wrote:
http://pcquest.ciol.com/content/editorscolumn/techetete/2010/110010801.asp
I think we are losing the value of Open Source. The core objective of Open Source has been to let people learn the internals of a software application with the help of source code, and improve it further so that everyone benefits.
[...]
Let's understand this with my favorite example-Anaconda installer for RedHat based Linux distros. Anaconda is a fantastic piece of software, but it lacks documentation. So to modify it, you have to be a reverse engineer, and not a software developer. Therefore, contributing to its further development is difficult.
As someone who has actually hacked on anaconda I can say this is 100% nonsense as far as anaconda is concerned, because:
a. Anaconda is a distro installer -- the Fedora/Red Hat/Red Had based system's installer !! It is not an application per-se, and the very nature of a distro installer implies that there will be a new release every 6 months which implies that there will be very specific changes to complement changes introduced by the distro. For example, change from ext2->LVM->ext3->ext4 between the FC6 (?) to F13 releases. Now, /despite/ this
b. Anaconda /design/ and structure are *very* well documented: https://fedoraproject.org/wiki/Anaconda/SourceOverview
c. Even the general structure of the two stages of the installation are well documented: https://fedoraproject.org/wiki/Anaconda/Stage1DevelopmentGuide https://fedoraproject.org/wiki/Anaconda/Stage2DevelopmentGuide
d. The anaconda community is /very/ helpful knowing full well that people who do what to hack on anaconda might be a bit lot/intimidated by the source code. So, what might be missing in documentation is more that made up in the mailing-list archives or better yet by asking a question.
That article is just a rant for the sake of a rant -- no substance, no research. I doubt the author even ever wanted to hack on anaconda.
cheers, - steve