Oh Most Noble and Gracious Emacs, please be in -*- org -*- mode! This is mostly todo items for the 2nd edition, plus some random other stuff. Many items here may not make sense to people other than the book's author. This file is probably not complete, either. If something you expected to see here is missing, the omission is probably not intentional. * http://www.mikealrogers.com/posts/generation-gap.html On GitHub and the "amateurization" of open source projects. * Arches project as example of why attention bandwidth / resources can mean heads-down initial development makes sense sometimes. See Koen van Daele's mail about this ("Re: Arches") Aug/Sep 2012. * On POSS site, link to CivComs blog posts, CivComs Wiki, etc. * Changes for 2nd edition ** OpenHatch / peers@ list ** Comb Jono Bacon's book again for topic coverage. ** Dreamwidth ** Ask around! ** Consortiums (OIC Weave, that first responder app, etc) ** jorendorff's question about read access to security bugs, apparently an internal debate at Mozilla citing http://blog.gerv.net/2011/12/a-level-playing-field/ which cites POSS story about Mike Pilato and commit access. See IRC transcript in #red-bean of 2012-08-15. ** GitHub, bug trackers update ** Look on foundations list for some recent discussions, e.g., "advice on branding and open source communities" ** OSS and gov't - the DNC thing with Paul Smith: interesting case study - check civcoms wiki of course - COTS, FARS, etc - Ask Simon about EU - What about the rest of the world? May have to punt :-( - Most of what govts are concerned about are not really open source vs proprietary issues. Procurement, vendor availability, quality of the system, transition costs, need for retraining (OpenHMIS), long-term maintenance costs, etc... Take open source and licensing issues off the table, since these buyers don't usually negotiate about licensing anyway. Address functionality and support services. Open source should be about the seventh bullet point down (credit Gunnar Hellekson). But do watch out for misconceptions about the availablity of support, quality of UI or of admin UI or of back-end implementation. Advantage of open source is data repurposability -- it can better meet reporting needs, data quality needs, will tend to use standardized formats, etc. ** See Mel Chua's mails ** http://dreamsongs.com/IHE/IHE-62.html ** From Wolf Peuker Date: Tue, 02 Oct 2012 10:58:11 +0200 First, I was working on the IRC section, there was a list of open source pastebin sites (gray box): http://producingoss.com/en/irc.html What do you think on Gist https://gist.github.com/ as run by GitHub? Is it popular? Should it be in the list? Second, I translated RSS section into German. There were some readers mentioned. I think modern mail clients or browsers can be used to. I don't know if it's really popular, but I read RSS only within Thunderbird, my mail client. Should this be made explicit? ** From Wolf Date: Tue, 02 Oct 2012 17:23:34 +0200 Hi Karl, here you predict it, now it's become true ;-) > (no Git, at least not yet) http://producingoss.com/en/web-site.html#canned-hosting-choosing ...but I think this should be updated. *** note that web-based presentation of diffs on Google Code is thought ugly by some; compare to SF or GitHub. GitHub has commenting on commits (line-based if nessesary!), though, and it's fast too. ** From Kit Plummer From: Kit Plummer Subject: Re: [mil-oss] November mil-oss Book Club To: mil-oss@googlegroups.com Date: Mon, 5 Nov 2012 07:32:09 -0700 Reply-To: mil-oss@googlegroups.com Very cool Karl. On the topic of [1] I hope that the intent is to discuss the value of DVCS and not necessarily Github specifically. When I first read the book (back in '05), the biggest challenge for me wasn't the tactics of running an open source project, but the complexities associated with cultural requirements at executive, project management and engineering levels. I'd love to see a section in "Setting the Tone" identify with this a bit. I know you've covered well the "change" as it affects developers… Thanks. Kit ** David Eaves's "Science of Community Management" http://eaves.ca/2012/11/15/making-bug-fixing-more-efficient-and-pleasant-this-made-me-smile/ http://www.youtube.com/watch?v=TvteDoRSRr8 ** Look at this Dr. Dobbs piece. http://www.drdobbs.com/jvm/creating-an-open-source-project/240145389 ** "Bus Factor" (suggested by Philip Olson , later a KS pledger) ** Importance of real-life events (conferences, code sprints, hackathons, etc) From http://keimform.de/2007/freie-software-produzieren/ (translated): What is also missing, the importance of real-life events, ie conferences, code sprints, Doc sprints, work camps, etc. From my perspective and experience are such meetings for the social process in an active community is very important. ** http://gabriellacoleman.org/Coleman-Coding-Freedom.pdf ** Open Source Software Licenses versus Business Models (Stephen Walli) http://www.networkworld.com/community/node/82215 Also this by Stephen: http://www.outercurve.org/Blogs/EntryId/77/Which-Open-Source-Software-License-Should-I-Use ** Check out Simon's columns, of course. ** "Open source policy no guarantee governments will actually use open source" from FierceGovIT ** Look over mil-oss posts in general ** http://www.bitsandbuzz.com/article/which-open-source-license/ ** Journalists (e.g., using NYC financial transparency site) need their questions and bug reports embargoed. In general, there may be a need for bug curation, editing assistance, delay, consolidation, etc. This is just one example, and it's not only journalists. ** Dustin Mitchell's comments: https://plus.google.com/u/0/105883044168332773236/posts/GPEj7Rm4C3w ** See comment from Agog Labs on Kickstarter project page. ** Mark Atwood re Open Stack ** One Kickstarter reader asked: "Will you be going into greater detail about managing cultural issues in open source projects, like trolls, doxing, sexism, harassment, or bullying?" ** * Explanation of POSS web site to ORM: The online version has some properties that I'd like to maintain -- the most important is probably the human-readable anchor names, for example: http://producingoss.com/en/forks.html#forks-handling It's not just that they're human-readable, it's that they stay stable no matter how content moves around. I could move the material about forks to a completely different chapter, but the URL would stay the same (and when someone went to it directly online, they would automatically be in the right chapter when they got there, whatever chapter it is). Out on the Net, people refer to particular parts of the book using those section & anchor names. So I can't afford to break those.