ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

Hacking should be about making things

(1/1)

phitsc:
Drew Crawford just posted a rant about how hard (impossible?) it is to land patches in many an open source project. It's an enlightening read which will actually make you think twice if you should finally start getting into OSS by starting to create patches for your next favorite piece of open source software.

Another of Drew's posts well worth reading is: Why mobile web apps are slow

mouser:
The Drew Crawford post looks like a great read, thanks for sharing that.

IainB:
Hacking should be about making things?
I had always understood that was one of the meanings of the verb "to hack".
For example, from the Microsoft Computer Dictionary (5th Ed. from 2003):

* hack1 n.
1. A modification to the code in a program, often made without taking the time to find an elegant solution.
2. A sloppy job. See also kludge (definition 2), patch1.


* hack2 vb.
1. To apply creative ingenuity to a programming problem or project.
2. To alter the behavior of an application or an operating system by modifying its code rather than by running the program and selecting options.


* hacker n.
1. A computerphile; a person who is totally engrossed in computer technology and computer programming or who likes to examine the code of operating systems and other programs to see how they work.
2. A person, more commonly considered a cracker, who uses computer expertise for illicit ends, such as by gaining access to computer systems without permission and tampering with programs and data. Also called: cracker. See also hacktivist.


* hacktivist n. An individual who furthers political or social agendas through hacking activity. Hacktivists may break into computer systems to disrupt traffic or cause confusion, and may alter Web pages or e-mail to display content sympathetic to a specific cause. See also hacker.

Edvard:
I have contributed two patches to an open-source project and contributed documentation to another.  One got accepted because it solved a long-standing spelling error for a macro that "nobody used, but what the hay, let's merge it because it's valid".  Another was not accepted, but pending whether I can come up with similar functionality for the other toolkits, it may be.  The third was documentation for configuring a piece of software (now an abandoned project) that had NONE when I was trying it out, and I weighed two options: send hate mail (because it was that frustrating) or put in writing what of it I had managed to grok and submit to the author.  I and the (then) project maintainer were glad I chose the latter.

So, all in all, I've had good experience with it.  Great article either way. :Thmbsup:

Navigation

[0] Message Index

Go to full version