{"id":100,"date":"2008-04-24T12:56:22","date_gmt":"2008-04-24T18:56:22","guid":{"rendered":"http:\/\/www.philhassey.com\/blog\/2008\/04\/24\/how-to-run-an-open-source-project\/"},"modified":"2008-04-24T12:58:06","modified_gmt":"2008-04-24T18:58:06","slug":"how-to-run-an-open-source-project","status":"publish","type":"post","link":"https:\/\/www.philhassey.com\/blog\/2008\/04\/24\/how-to-run-an-open-source-project\/","title":{"rendered":"How to run an open source project?"},"content":{"rendered":"<p>If I were going to OSCON, I&#8217;d certainly go to <a href=\"http:\/\/en.oreilly.com\/oscon2008\/public\/schedule\/detail\/2682\">this talk<\/a>.  But I&#8217;m not planning on it, so &#8230;<\/p>\n<p>&#8230; So I&#8217;ve got that tinypy project sort of taking off.  It&#8217;s got a SOC student (thanks google &amp; PSF) and a bit of interest.  So far most of the open source projects I&#8217;ve done haven&#8217;t generated more than a couple patches &#8212; in their lifetime.  With that in mind, I&#8217;m not entirely sure what is a good way to accept patches and run a project, since I don&#8217;t have loads of experience in it.  I&#8217;m a &#8220;solo&#8221; dev in my day job as well.  I want to do a decent job of managing the tinypy community without having to work too hard.<\/p>\n<p>Do I take whatever people give me and patch it as-is and just figure, well, someone else will fix it?<br \/>\n<em>Obviously not.  Especially not for tinypy where &#8220;good&#8221; and &#8220;concise code&#8221; is of such large value to the project.  And with the SOC coming up, &#8220;secure code&#8221; is also very important, as well as testing.<\/em><\/p>\n<p>Do I be really strict and keep rejecting a patch until it&#8217;s &#8220;perfect&#8221;?<br \/>\n<em>Maybe?  I remember submitting a patch to one project ages ago, and it got rejected without much good explanation.  I&#8217;ve also submitted others successfully.  Not quite sure what the balance is.<\/em><\/p>\n<p>Do I take the patch and apply it and then fix things up myself?<br \/>\n<em>Maybe?  If it is easy to fix &#8230; but then again, why should I have to do all the work?  I don&#8217;t really have <strong>that<\/strong> much spare time (all evidence to the contrary.)<\/em><\/p>\n<p>How do I grow the project (in general) without it turning into a monster?<br \/>\n<em>Stick to my guns on the 64k code limit*?  Maybe not, since things like VC support, security, etc, are going to take up *some* bytes.  Not to mention, tinypy could use a few batteries &#8230;  At the same time, I&#8217;ve gotta draw the line <strong>somewhere<\/strong>.<\/em><\/p>\n<p>Obviously some common sense is needed here, but sometimes I run a bit short on that.  Advice \/ links to good articles would be swell at this point.  I could google this sort of stuff, but I think having the context of responses from a community I know would be much more valuable here.<\/p>\n<p>-Phil<\/p>\n<p>* on that point, I think having the 1.0 source always in the &#8220;featured downloads&#8221; might be a good idea.  Even if the project gets bigger, people can still check out the &#8220;classic version.&#8221;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>If I were going to OSCON, I&#8217;d certainly go to this talk. But I&#8217;m not planning on it, so &#8230; &#8230; So I&#8217;ve got that tinypy project sort of taking off. It&#8217;s got a SOC student (thanks google &amp; PSF) and a bit of interest. So far most of the open source projects I&#8217;ve done [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,2,32],"tags":[46,43,45,44],"class_list":["post-100","post","type-post","status-publish","format-standard","hentry","category-development","category-python","category-tinypy","tag-community","tag-help-me","tag-open-source","tag-patches"],"_links":{"self":[{"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/posts\/100","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/comments?post=100"}],"version-history":[{"count":0,"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/posts\/100\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/media?parent=100"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/categories?post=100"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.philhassey.com\/blog\/wp-json\/wp\/v2\/tags?post=100"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}