This post by Jeff Atwood talks about giving money in exchange for features or bug fixes in open source projects. Although there is a long explanation for why most users can't really help open source, the basic understanding of open source is lacking. Well Jeff, this time you just don't get it.
The phenomenon of Open Source is heavily discussed and analyzed, mainly in "the Cathedral and the Bazaar", but also in printed newspapers like the Washington Magazine, where which motivation of open source developers is analyzed.
The main reasons of motivation are:
Doing something that hasn't been done before
Making things that really work
Prestige - being reviewed by peers
There is difference between sizes of open source projects. There are large like Mozilla or Apache that are backed up by a company, and there are small ones, like Zlib and others. Large projects, having full time developers might benefit from money given for fixes / features.
For small open source projects, the idea of paying developers is questionable at best due to several reasons:
Contributors work on the project on spare time and not as full time job.
The reasons people are motivated are not money, as mentioned above.
What people need is more time, to be able to implement their own ideas and to react to the community, as they see fit.
What if a developer becomes for hire? Can he follow the paradigms of open source?
I believe that a programmer for hire in open source is a dangerous thing, because of the different motivations. A for hire programmer night not code the solution bet for the project, but might look for a short term solution. The contribution might not be accepted by the maintainers, giving additional problem for the client.
Regarding the post itself, Jeff "forgets" his own experience in donating money to open source projects, where the money given to an open source project is left unused.
A few days ago I attended a meeting regarding knowledge management for a services group and to see if it can be suitable for our group as continuation for the wiki initiative (see here and here).
The presentation was about the ideas of Knowledge Management, generating a heated discussion regarding roles and relations to content management.
From Wikipedia:
Knowledge Management (KM) comprises a range of practices used in an organization to identify, create, represent, distribute and enable adoption of insights and experiences. Such insights and experiences comprise knowledge, either embodied in individuals or embedded in organizational processes or practice.
Content management, or CM, is a set of processes and technologies that support the evolutionary life cycle of digital information. This digital information is often referred to as content or, to be precise, digital content. Digital content may take the form of text, such as documents, multimedia files, such as audio or video files, or any other file type which follows a content lifecycle which requires management.
In a broad perspective, Content Management is a phase in Knowledge Management.
This definition raises some problems of Knowledge:
Knowledge is by definition what is stored inside people's head.
Content is what we get when trying to document the information provided by same person.
Sharing is allowing other persons to use the information and create internal knowledge.
My goal is to help lower the barriers for content generation and content consumption, so instead of using email for transfering pieces, other solutions can be discussed. I believe that WEB 2.0 technologies can help, but each one in a different context:
Blogs can be used for content push, for information that is short lived and mostly static.
Forums are a great place for information sharing, but they are even shorter lived, while having a limitation of not being concise.
Wikis can be used for longer term information, while allowing bi-directional communication (the discuss page).
There is no optimal solution for creating information, and makig users gain knowledge, but as a first step, lowering the barriers for generation and consumption is quite acceptable.
The book “Time enough for love” by Heinlein has a section about a man who was too lazy to work hard, so he tried to think about every task he had and make it as easier as possible. As strange as it seems, this is kind of a role model for the way I try to approach design.
The slogan “Just do it” has an appeal for using the first idea you have. The only problem is that the first idea or design might not be most effective or elegant. Unfortunately, the first idea, without research, might lead to a brute force approach that although might provide a solution is ineffective and inelegant. The act of design, on top of allowing better communication, can be used for constructive laziness: to spend some time researching, testing, trying to isolate the real task and optimize it.
Most coders I know don’t like to work hard, but there is a difference between working hard for coding and working hard before, in the design phase. The design phase can be hard work, where the design is tested several times, iterated, shared, commented and stripped. The goal is to find the weak spots of the design and understand the quality attributes.
The relative simplicity and elegance is reflected in the quality attributes of the solution, as exhibited in the documentation and presentation of the design. Same as code reflects its elegance while read the same is relevant for design but more explicitly. The elegance of the design can be seen in the separation of layers, the encapsulation of internal attributes, symmetry of connections and balance between conflicting requirements.
True elegance comes when the constructive laziness becomes a state of mind for selecting how to spend the time and effort. When the design reflects creativity, elegance, balance of selections and real effort then one feels a sense of completion and love of the profession.
The last months there has been a lot of FUD regarding SSD vs. regular HD. Most of the ambiguity was regarding performance and suitability to different usages and whether it was really something different.
Mechanical hard disks use a magnetic plate for storing the information using a read / write head. The plate is divided into concentric circles, and each circle is divided into short stripes each storing a specific amount of information. A more detailed explanation can be read in howstuffworks.
SSD use memory chips for storing the information same as RAM, with the difference that the information is persistent until next change.
There are three concerns in hard disks:
Throughput - how many bytes can be moved between the computer and the hard disk in a defined period of time, this is normally measured in MByte / sec for a stated block size.
Latency - the time it takes from the moment you request an action until it is really executed on disk, this is normally measured in milliseconds.
IOPS - the number of read or write actions that can be performed in a defined period of time, this is normally measures in IO per Second for a stated block size.
In mechanical disks, there is a limitation on how fast the head can reach the sector to be read / write, it affected the latency due to the head having to reach the start of the file, the IOPS and throughput because of repositioning of the head in middle of files.
In order to alleviate the problem of head movement, different methods were used, like Native Command Queuing and disk defragmentation.
The SSD does not have a problem of head repositioning because each sector is fetched directly using a direct mapping from memory. Thus methods used on mechanical disks like defrag or NCQ are not relevant. SSD have a limitation on throughput due to the time it takes to read a sector from memory.
Just to understand the different performance benefits, here are 3 disks to be compared:
As you can see, there is a huge difference in IOPS for SSD, but a lower benefit for sustained transfer of sequential information. This raises the question of best use of SSD taking into account the price of one disk.
The best practices form EMC specify that SSD should be used for IOPS intensive use, like DB indexes of frequently accessed small files. The SSD is currently unsuitable for storing large files requiring high throughput.
As always in engineering, each option has a different tradeoff, and with enough clear information a judicial decision can be taken:
SATA - high density, low price and medium throughput
FiberChannel - low density, higher price and very high throughput
SSD - lowest density, highest price and very high IOPS
The future might hold surprises in capacity and price, but it will take some time till there is only one winner.
