What is acceptable as 'open-source'? [was Python vs C++]

[Chris Angelico]

On Wed, Aug 27, 2014 at 5:50 PM, Frank Millman <frank at chagford.com> wrote:
>
> This is quite a timely message for me. I am inching closer to releasing a
> version of my accounting software, and a lot of the above comments apply to
> me as well. At present I am the only developer, and my project is not hosted
> anywhere, so I have to decide how to make it available, and I am open to
> suggestions.
>
> I have had two attempts at running an hg repository locally, and I am afraid
> that I am not keeping it up to date. I do have a master copy, but I have
> made so many changes in my clone that a merge will not make any sense, so I
> will have to start afresh. I think that making it public will be the only
> way that I can force myself to update it regularly.

Then you need to develop a new style of working, which plays more
nicely with source control. Instead of hacking on whatever you feel
like doing and then committing to source control later, make each
change and immediately commit it. Get into the habit of putting useful
commit messages onto your changes. As you say, making it public will
help you force yourself to keep that up-to-date.

> I could stick to hg (or git) but I have recently come across fossil, and it
> seems ideal for my needs. Has anyone used it? It seems to have everything it
> needs (a wiki and a ticketing system) for self-hosting, and I have my own
> domain that I have not activated yet, so maybe I should just use fossil and
> host it myself. Any comments?

I haven't used fossil personally, but I'm not really a fan of
all-in-one systems; they're somewhat inflexible. If you don't like the
wiki, you're stuck with it. I'd rather work with all the parts
separately - change one and it doesn't affect anything else.

But if all fossil's parts suit you, then by all means, use it!

> Documentation is a mess. I did start using Sphinx a while ago, so there is a
> sprinkling of rest-format docstrings, but they have not been kept
> up-to-date, and in some cases are out of date. There are plenty of other
> comments in the code, mostly reminders to myself about various issues. I
> don't know open-source etiquette. Should I spend the time to sort this out
> before going public, or is it acceptable to leave it as is for now?

Go public first, and watch what people get confused at - then document
those parts. If you try to document everything first, you'll spend
heaps of time and effort on it, and maybe won't even be happy with the
result.

ChrisA