Connecting Kallithea and RhodeCode

Thomas De Schampheleire patrickdepinguin at gmail.com
Fri Sep 9 12:39:18 UTC 2016


Hi Dmitry,

On Thu, Sep 1, 2016 at 11:53 PM, Dmitry Konchalenkov
<dmitry at rhodecode.com> wrote:
> Andrew,
>
> Thanks for looping in other members! I'm sorry if my email came across the
> wrong way. The tracking code has nothing to do with intentions: it’s being
> applied by a popular Gmail plugin. I’ve disabled the plug-in for this reply.
>
> I want to follow up on just two points: collaboration and RhodeCode’s CLA.
> My goal was to find out how best to invite any interested members of the
> Kallithea community to also join our community. RhodeCode uses the AGPLv3
> license. Like yours, our community is open. We respect the skills and
> creativity of the people on this thread. I’ll reiterate the invitation here.
>
> Second, RhodeCode’s CLA does not require any copyright assignment. It also
> does not impose restrictions on what the copyright holder (contributing
> developer) can do with their work. It’s on our web site for any potential
> contributors to see up front.
>
> I am here not to debate the relative merits of our respective licenses or
> goals. More than willing to answer questions about our project and related
> topics, if there are community members who are interested. My regards to the
> people on this thread and thank you again for putting me in touch.


I'm not going to discuss licenses, copyrights, or consider historical events
that I was not part of, and instead just zoom in on your goal of better
collaboration between RhodeCode and Kallithea.

If I understand you correctly, you would like to encourage existing Kallithea
contributors to also contribute to RhodeCode, is that correct?

Similar to what Søren already said, I wonder what would be the benefit of that
to such a contributor. I think it is safe to assume that any contributor will
only be working with either of Kallithea or RhodeCode, but not both. They may
work at a company where one of these products is deployed, or they may be using
it for personal projects, or they may just be interested in contributing to an
open-source project without really using the product directly. Either way, the
goal would be to improve the product they are interested in, why would they
start improving another quite similar product, even not considering the extra
work it would bring?

I'll assume that you would like such better collaboration because you have
noticed that the Kallithea project is evolving and there have been several
changes that you are also interested in. Perhaps you like our upcoming
switch to Turbogears2 coming from the dead Pylons framework, or our equally
upcoming switch to Bootstrap-based styling, or our introduction of Alembic for
database migrations across up- and downgrades, or our general cleanup of the
code base.
I can very well understand that. After all, all these changes are being made
available for free (under the GPLv3 license of course) and a company wanting to
use all this does not need to pay a dime as long as they respect the license.
In your original RhodeCode model, all development had to be done by the
RhodeCode company and that is expensive. In your current model, you hope that
you can get 'free' contributions from the community, while still being able to
make money on the product. But perhaps it does currently not give the benefits
you had hoped for.

Here is my free business advice to you: switch away from creating a product
yourself and selling it. Instead, do either (or both) of these things:

    1. Sell consulting/maintenance services for Kallithea, that is: people can
    pay you to make changes to Kallithea so it better fits their needs.

    2. Provide a hosted Kallithea service, that is: people can pay you to have
    their repositories hosted under Kallithea but on your servers, and you take
    care of all maintenance of the servers, application, etc. This is similar to
    what GitHub, BitBucket, etc. are doing.

If while doing so you make changes to Kallithea, my advice is to contribute them
back to the Kallithea community (that is, if it is not already obliged by the
GPLv3 terms; this depends on whether you actually distribute this modified
version). After all, keeping such changes to yourself involves a maintenance
cost of rebasing them to newer Kallithea versions, and that cost will increase
when the amount of changes increases.

I think such model has proven to work for countless other open-source projects,
so why wouldn't it work for you?

Best regards,
Thomas


More information about the kallithea-general mailing list