Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>Software structures underwent a radical change as their development teams became distributed across time and space, as shown in Figure 1b. Instead of a centrally planned, top-down, linear structure, code structure became network-like. Shortage of programmers, lower labor costs in emerging countries, and lifestyle preferences of the extreme programmer all contributed to this tectonic shift.

That paragraph is not explicit on whether he's talking about open source collaboration vs corporate distributed teams but since his references include FLOSS and "social coding" on github open software, I'll assume "open source" to interpret the following 2 paragrpahs:

>Stigmergy ensures tasks are executed in the right order, without any need for central planning, control, or direct interaction between the actors performing the work. [...] Markers make stigmergy more efficient, by more reliably focusing a programmer’s attention on the most relevant aspects of the work that needs to be done.

These are interesting ideas but I think any benefits of markers[1] are drowned out by the desires of programmers who are not beholden to a manager's agenda. Programmers volunteering to contribute often work on what is interesting to them.

It's very unlikely for a volunteer programmer to wake up with the irresistible desire to "hunt for memory allocation bugs in OpenSSL to prevent heartbleed". On the other hand, a Microsoft manager can direct one of his programmers to add a shim to Windows Vista so Quicken 2005 is compatible and future customers upgrade without fear. That type of work is drudgery but he's getting paid a salary and doesn't pick his tasks at random.

A stronger lever than "pheromone markers" in source code is sponsorship. E.g. a corporate entity finds value in an open source project but there are some gaps that programmers are voluntarily working on. The business entity pays a salary to programmers to prioritize that work higher and get them done.

[1]Don't know about Tesseract but it's probably something beyond sprinkling markers such as "//TODO: optimize this function is next highest priority" throughout source files or overhauling github to have a leaderboard of "important things to do next"



>It's very unlikely for a volunteer programmer to wake up with the irresistible desire to "hunt for memory allocation bugs in OpenSSL to prevent heartbleed".

Honestly, I find that kind of work fun. The problem is one of incentives, in that features are more highly valued than unknown bugs.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: