

Ask HN: Setting up an open source project. - jawngee

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:<p>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.<p>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?<p>Thanks for any input.
======
SwellJoe
We've got a couple of projects at SourceForge.net, and I have to agree with
everyone else. It is slow, and it's interface has always been pretty clunky--
dealing with tickets and the forums is pretty horrible. I wouldn't use it
today.

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.

~~~
jawngee
Thanks for the download.

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.

~~~
william42
I'd say that "of the PHP mindset" is quite possibly one of the worst insults
you can give code.

------
rahulgarg
Google code is a good place to host. Very fast to get started and you get a
very clean website with all the basic tools. Bug reporting is simple so your
users will be happy too. It uses SVN but google give you the option to host
your repository somewhere else if you dont like SVN. However Google allows
only a restricted set of licenses so you need to check their list of supported
licenses.

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.

------
ezmobius
I'd recommend github for source hosting. I've got multiple open source
projects that I run or use that use github for scm and use lighthouseapp.com
for ticketing. These are fairly large OSS projects with many many contributors
and it works great. <http://github.com/wycats/merb-core/tree/master> and
<http://github.com/evanphx/rubinius/tree/master> as well as a bunch of other
smaller oss projects.

Both github and Lighthouse will give free accounts to open source projects.

------
aditya
github is great for forking and the like, I'd go with that and lighthouse for
tracking and google groups for a mailing list.

Or, you could just run your own git repo, trac, and mailman.

Just stay away from sourceforge.

~~~
piers
See, I was going to mention SF. It seems to be becoming less and less popular
these days. Why is that? Do you think it's become too big for its boots?

~~~
jawngee
My impression is that it's painfully slow and the UI is horrid. Six clicks to
download a package and it's not very clear even then.

------
st3fan
At Polar Rose we simply started to put projects on Google Code. Some are well
documented, others are mostly code dumps and need more attention. We use
subversion internally and Maven for working with well defined (Java)
components/libraries. So there is not much difference between working on code
hosted in the public or private repositories.

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.

------
tomh
We have something on SF which we don't update often because of all the reasons
you've read in other posts. The up-to-date code snapshot is hosted in-house on
Subversion. Issues are tracked in-house with Mantis, user/developer mailing
lists are run in-house with Pipermail, the code is built on the server with
the help of Maven (since it's all Java, YMMV), and wikis hosted in-house with
the help of Dokuwiki.

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>

------
vulpes
I have a question that is along the same lines, if we have a project that we
want to open source and basically make money on service contracts what is the
best open source license to go with?

~~~
tomh
LGPL, we went with it for our code and have been doing okay by it. The only
trick is that we use a number of other OSS packages as well and we have to do
an audit every once a quarter to make sure the licenses are all in line with
ours.

------
fugue88
I'm hosting some projects on my own box. It's a mix of svn and bzr
repositories fronted by Trac.

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.

------
midnightmonster
It would be best to package your PHP additions as an extension if you could,
but I imagine you'd have done that already if it would work.

PHP on Ubuntu comes with the Suhosin patch installed, so there is at least one
third-party PHP patch that has some significant distribution.

------
pakmee
i did work on an open source J2ME api(BIZU ME) and stopped when I started
working full time. I can say that sourceforge is ok for hosting since that is
what I used for hosting and had no problems what so ever. The UI is weird to
deal with but its alright once u get used to it. I haven't tried any other
such as google code etc so I cant give u any feedback on those.. You will
probably need a bug tracking tool such as jira for tracking your issues. Jira
is really good and offers a free licence if your project is open source. Apart
from that , you will need weekly updates or else people lose interest pretty
quickly!

------
babul
Trac is great, and I've used it a number of times, but if you are rolling your
own platform then Redmine (www.redmine.org/) is worth considering as it is
much nicer and easier to get started with.

------
ivey
A big thumbs up for Github. I've got OSS and closed source projects in GH and
I absolutely love it. Pull requests are the new patch ticket.

