Ask HN: Setting up an open source project.
We have a ton of projects at massify.com we've been itching to open source, but we're obviously a little short on time. I'm wondering if anyone has actively participated or maintained an open source project and can help me answer some bullet points:
A. Has anyone ever started an open source project? B. Any recommendations for project hosting (github, sourceforge, google code, etc.) C. Tips on general project maintenance.
The biggest project is that we want to fork PHP. I'm not sure what kind of nightmare that would be. We have successfully been running a patched version of PHP that supports anonymous functions, closures and array shortcut notation. I guess this might be a whole different topic? Has anyone maintained a fork before?
Thanks for any input.
(
22 comments
| 22 points
| on HN
)
For our newer stuff, we handle it internally...but we have a slightly odd situation of having a commercial branch and a GPL branch, and the commercial branch is private. Open Source hosting places don't make that easy.
If I were starting a new project today, I'd try both github and Google Code and see which one I liked better, and then I'd go with it. git is really cool for highly distributed projects, but unnecessary for most projects with only a few developers--there are still some benefits, but if the Google Code tools work better for you, then the revision control choice probably doesn't matter enough to make a difference.
For one company I worked for a few years ago, we ended up building out a code hosting platform based on trac, Subversion, Mailman, Virtualmin to manage it all on the backend and grant project owners their own web space, etc. (SciPy.org is the result, and several Open Source Python scientific computing projects are hosted there. It works pretty well, or did when I last dealt with it about three years ago.)
Generally, it's more important to actually get the code out there than how you do it. Documentation is the hard part of the equation, and it's more important than you'd think. Your code will not be adopted without at least good documentation for installing it and getting it running. People will put up with a lot once it's installed and doing something productive for them...but if the install doesn't work, you've lost them, and they'll very likely complain about your software to others.
Forking a major project like PHP is dangerous mojo. I don't blame you...whenever I work in PHP, I feel like someone is stabbing me in the eye every time I have to create an array by typing "array(1, 2, 3, 4)" or try to do anything even a little clever. Have you talked to the PHP folks about possible inclusion in PHP 6? I mean, I know their mental model for software development is deeply flawed, and maybe they won't be eager to incorporate such dramatic changes, but if you could avoid a fork and still get the code out there, it'd be a win. Worst case, you should remain on friendly terms with the parent project--do not fork in anger, as it's bad for everyone involved. Do what you can to insure your bugfixes go back into mainline and that you follow their code very closely so that compatibility is maintained except in the specific areas where you diverge.
Re: forking. I'm not really involved in PHP internals beyond keeping an eye on it, but there have been some really brilliant patches by a single guy that keep getting rejected because they're not of the "PHP mindset". Honestly, I think their mindset is a little f'd up. The namespaces in PHP 6(5.3) are ugly as hell.
We wouldn't be forking in anger, we'd just be posting the latest PHP with patches that make it useful. Use it if you want, that sort of thing.
Anyways, thanks for the feedback.
launchpad is also an ok place to host code (and it allows any license) but it doesnt host wikis for example and some of the UI elements are rather radical and may not suit your taste. if you host on launchpad, you will need to host a proper website and/or wiki somewhere else.
Dont go with sourceforge. The site has become slow and full of ads which cover half your screen. The interface is clunky too.
edit : launchpad uses bazaar a distributed VCS.
Both github and Lighthouse will give free accounts to open source projects.
Or, you could just run your own git repo, trac, and mailman.
Just stay away from sourceforge.
This is ok if your project is targetted at users who are developers, but if you want fresh blood and the less (initially) motivated to get drawn in a priority should be:
* A concise explanation of what the project is.
* A nice forum. Maybe even with no registration until you get established.
* Easy bug reporting. (Maybe not a bug tracker - a forum for bugs can be really effective provided the dev's or some support people read it.)
The most difficult thing was actually not a technical thing but a mindset issue: To teach people in the teams how they can identify components that can be released as open source. And to actually do it.
Why all the in-house stuff? Control, for one. We also ask for registration information before giving access to the source code. This comes around to lead generation when it's time to sell services (which is all the time).
Check it out: http://www.openclinica.org/index.php
Trac is awesome, but it doesn't really understand bzr branches and such, so linking to code from inside Trac is a little weird. If you'll be using DVCS, shop around for something more congruent.
Also, browsing a bzr repo from Trac is pretty slow.
PHP on Ubuntu comes with the Suhosin patch installed, so there is at least one third-party PHP patch that has some significant distribution.