Transifex has become proprietary

Miroslav Suchý msuchy at redhat.com
Fri Jul 18 14:25:08 UTC 2014


On 07/15/2014 10:41 PM, Dimitris Glezos wrote:
> The data we have is that very few people used (and use) the open-source version of Transifex. Some of those who did,
> were using an even older version of Transifex (0.9) which we weren't actively maintaining. We have asked around and
> carefully reviewed whether a move like this will have a measurable outcome. In the end, there is an open-source repo
> available [1]. It's old and unmaintained, but it's there to fork and hack on.

I'm not sure you correctly understand me.

I give you an example:
I am working on Copr [1], which is provided as service. But I provide source codes [2] as well, despite the fact that 
there is *no one* else running other instance of Copr.
In fact - if you would like to start new instance of Copr you will have hard times and it will take you non-trivial 
amount of time.
Some of the data/code/information are in copr.git. Some are in public Fedora infrastructure git and some are in private 
infrastructure.git. My goal is just one. Operate that one instance [1]. And providing sources is "just" side effect. 
However I'm not spending my time and resources to tune up the code, so it can be run somewhere else.
If somebody would be interested in running separate instance and (s)he encounter some obstacles, then it would be *his* 
work. His work to contribute and maintain it.
And despite all of these - people still contribute to Copr. By ideas. By code, although I have to verify it. And it is 
open source project.

To conclude - I suggested that you provide your current source (sans passwords and other data you feel as confidential) 
while stating that this is code for *your* instance. And if somebody wants to run *their* instance, there must be done 
some work, but nobody from your team will do it. People are on their own.

[1] http://copr.fedoraproject.org/
[2] https://git.fedorahosted.org/cgit/copr.git

-- 
Miroslav Suchy, RHCE, RHCDS
Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys


More information about the infrastructure mailing list