How to run an open source project?
If I were going to OSCON, I’d certainly go to this talk. But I’m not planning on it, so …
… So I’ve got that tinypy project sort of taking off. It’s got a SOC student (thanks google & PSF) and a bit of interest. So far most of the open source projects I’ve done haven’t generated more than a couple patches — in their lifetime. With that in mind, I’m not entirely sure what is a good way to accept patches and run a project, since I don’t have loads of experience in it. I’m a “solo” 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.
Do I take whatever people give me and patch it as-is and just figure, well, someone else will fix it?
Obviously not. Especially not for tinypy where “good” and “concise code” is of such large value to the project. And with the SOC coming up, “secure code” is also very important, as well as testing.
Do I be really strict and keep rejecting a patch until it’s “perfect”?
Maybe? I remember submitting a patch to one project ages ago, and it got rejected without much good explanation. I’ve also submitted others successfully. Not quite sure what the balance is.
Do I take the patch and apply it and then fix things up myself?
Maybe? If it is easy to fix … but then again, why should I have to do all the work? I don’t really have that much spare time (all evidence to the contrary.)
How do I grow the project (in general) without it turning into a monster?
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 … At the same time, I’ve gotta draw the line somewhere.
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.
-Phil
* on that point, I think having the 1.0 source always in the “featured downloads” might be a good idea. Even if the project gets bigger, people can still check out the “classic version.”
April 25th, 2008 at 7:28 am
* http://video.google.nl/videoplay?docid=-4216011961522818645 by two SVN developers
* http://www.oreillynet.com/onlamp/blog/2005/10/ofun.html – about Pugs
* The classic http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
Good luck,
Miki
April 25th, 2008 at 11:19 am
Miki – thanks, I’ll read that stuff 🙂
April 25th, 2008 at 5:37 pm
Great help – I’ve reviewed that stuff. The “classic” I’ve read before and didn’t do so much for me… I wasn’t quite sure about the pugs one either. The subversion talk really felt right to me.
So I’m going to implement a number of those ideas:
– writing a quick mission / scope statement – so people know what the goals of tinypy are
– set up tickets / commits to go to the mailing list so everyone knows what is going on
– do a review process on a few patches per person and if they work well, give them commit
March 18th, 2009 at 8:21 am
If you thinking beyond your 64k limit, make it scalable. The extra set of features come at a premium but always the core system remains under the 64k!