Is this repo alive?

[ecarreras]

This repo seems dead, the last commit is from 7 months ago, and it only adds a new language... I see that transifex.com is so differnt from the version of this repo? Seriously all the development of transifex is done here?

The release cycle[1] is also outdated, the last version that I can see is 1.2.1 [2]

We can see the repo network[3], and there is some people doing commits and working on it. Some of they are:

@pejakm @fazakis @tymofij @soslan @Lockal

Why not create a main community edition fork? and send back pull-requests to official transifex repo?

[1] http://help.transifex.com/server/releases/index.html#transifex-releases
[2] http://help.transifex.com/server/releases/1.2.html#transifex-ce-1-2-1
[3] https://github.com/transifex/transifex/network

[soslan]

I do support you. Moreover I think we should create something independent and really open.

[ecarreras]

In fact, we are thinking to move to another platform, and we are evaluating it. It seems really open and has much more activity. We love Transifex, but this is not the path...

[pejakm]

Well, there's a 102 issues in the tracker, nobody bothers to take a look. Forking seems logical step forward.

[tymofij]

They have not only stopped pushing things here, but also changed their development model from "Transifex CE + proprietary addons = Transifex.com" to having one big integrated internal repository. Chatlog here tymofij/transifex#1 (comment)

And even before that, for the couple of years that I am aware of, the project was not truly opensource: it was steered and driven by employees, the intentions were never clear and decisions were announced after the deed, if ever. Also, important things like localizer dashboard or messaging system were never opensourced.

I have my own fork, but I feel very lonely with the amount of work pending. Like fixing the tests, migrations, requirements and updating the code to Django 1.5. Working in a team would be great.

Question is, would legacy TX code be worth it. @ecarreras - what is that other platform you are considering?

[ecarreras]

@tymofij the platform is weblate[1], it seems that have a lot of activity[2], it is also in Github and written in Python 👯

Another interessant features are git integration, and github hooks, we are still entering on it.

[1] http://weblate.org/en/
[2] http://www.ohloh.net/p/weblate
[3] https://github.com/nijel/weblate

[glezos]

Hi all,

Let me shed some more light and share some of the events which led to the current status.

Events so far

The Transifex team was and still is committed to open-source. Tx was born in the open-source community and we're really happy to be able to offer a hosted version of Tx for free to open-source projects. Just like Github does. Very few open-source-born teams evolved to a point where they can do this, and I'm proud we are one of them.

The way we developed Tx in the past was to have everything in the open-source repo and maintain an "addon" which changed the theme, added paid plans and a bunch of Txcom-specific optimizations. With time we developed some features which are only useful for big, paying companies such as deep analytics on the TM usage per user etc.

With time, maintaining this code setup proved to be harder and harder. The code was ugly and painful to maintain. It was hard to code new functionality, especially in the UI, and debugging was a mess. Coding was actually not fun at all in certain areas. Just adding a button on a menu required hacking. We ended up spending more time working on loosely-coupling everything than actually working on useful features for the users.

In the meantime, more and more projects decided to come to Transifex.com instead of maintaining their own instances (eg. Fedora). The same happened with companies which considered Transifex CE. After a while, for the open-source projects, I think only XFCE had its own actively used, customized instance of Tx, a version from 2010, which did not follow the current development. For most people, Transifex.com seemed to work very well.

At some point it became obvious that we've been spending so much time on a repo which was hardly used by anyone instead of focusing on the product which almost everybody used. We also found out that these issues bothered the vast majority of the companies which operate an open-source-friendly web service.

The change

GitHub is a great example of a product which fully supports the community but without the troubles we had. While they operate with a closed product, they have a bunch of libraries open-source, they develop all the features the community needs and offer a free plan for public projects. Maybe it's the case with SaaS apps, I'm not sure.

So we decided to give it a try and see how it goes. The decision was engineering-driven, not business-driven. All the engineers on our team are open-source believers and being open-source had a huge positive effect on the company. We had no issue whatsoever with our competitors looking at our code. On the contrary, it gave us a huge edge and confidence with our customers they could never have had.

The plan was to clean up a lot of things in the code and focus on improving the product in many areas with a clean mind and repo. The results were amazing: the past few months we've improved the product more than the last 1.5 years. Just look at the new editor as an example. In fact, with the move, we were able to answer more requests by the community because we could code faster. We were able to invest time extending the API, which made it even easier to work with the service.

In the past we were doing one release every 3 months, now, we're doing 3 every week. I was curious about the diff, so I generated this from the GitHub charts that compares this repo with the combined (Txo+Txc) one.

Since last year, we've had 2x more projects and 3x more users. There are over 6.000 projects nowadays, which is pretty amazing.

The future

The next step would be to open-source many of the libraries we use, such as django-events, our file importers and a few other elements which can actually be re-used by other open-source projects and be actually useful for patches and pull requests.

We will continue to work hard to make sure Transifex is an amazing product. The current plan is to continue doing this on the new, combined, closed repo. If you feel there's an important feature missing which needs to be in the product, just let us know. If you're looking to add some major piece of functionality and are a student, contact us and we might be able to get you an internship to work on it.

Concerning this repo, there is still very, very little interest from the community for us to continue actively maintaining it. If you feel otherwise, this repository will be available to anyone who wants to hack on it. Fork away, and twist our arm to contribute to your fork. :-)

Summary: Maintaining both an open-source repo and Transifex.com was becoming much harder with time and 99.9% of projects were hosted on Transifex.com anyway. We decided to switch to a GitHub model where we work on one non-open codebase and open-source the libraries which are actually useful for others.

[patcon]

This is pretty disappointing, to be honest.

[sembrestels]

You are closing the product because nobody were using it in the wild? Maybe the most people were using transifex.com, but there were people using transifex.com becasue it was free software.

And transifex live is patent-pending and you say that your team are open-source believers...

I'm very disapointed, and I'm not going to recomend transifex to anybody more.

Moving to https://hosted.weblate.org/

[GreenLunar]

Open source seems to work just great for WordPress (wordpress.org - software; wordpress.com - ads/pay service). But making your software closed, after gaining popularity - some due to being open-sourced, is your choice. Anyhow, I really don't care. I am displeased of helping - a small fraction, though - transifex.net to be more relevant.

[kfogel]

I appreciate the care you put into the above explanation, but if the decision was truly engineering-driven and not business-driven, then why not just host your entire repository out in the open with an open source license?

In other words, the fact that you "ended up spending more time working on loosely-coupling everything than actually working on useful features for the users" was due to your own decision to separate the code into a public version and a private version in the first place. If you wanted to reduce the engineering overhead, just move the private stuff -- yes, the stuff that's "only useful for big, paying companies such as deep analytics on the TM usage per user etc" -- out into the public repository.

After all, the main reason people cared that your repository was open source was not that they wanted to host their own version, but that they wanted to know that they could do so if they ever had to. In other words, that they had the freedoms that come with open source. It's okay if your public repository is primarily useful to you, and isn't so easy for outside developers to get involved in. No one, at least no one who has ever run a software product business themselves, would insist that you take on the overhead of community management and modularization. Everyone understands that you have to make the product work for your customers.

But that's no reason to make it closed source. Unless you're using proprietary libraries as part of the code now, there is literally no code change your developers could commit to the current closed, proprietary repository that they couldn't just as easily commit to a public repository. After all, it's just one line in .git/config, right? Everything else stays the same.

So I don't understand the statements that "The decision was engineering-driven, not business-driven" or "We had no issue whatsoever with our competitors looking at our code. On the contrary, it gave us a huge edge and confidence with our customers they could never have had." If this is still true, then why not do everything you're doing now, but just in an open source repository?

Or if those statements aren't still true, then just say so :-). From here, it really looks like a business-driven decision, unless I'm missing something...

@sembrestel's point about the pending patent is relevant too. Let me ask directly: what would Transifex do if another project (whether open source or not) used the same technique covered in the patent as part of their own translation platform software? Would you enforce the patent, i.e., file an infringement claim?

I want to recommend Transifex, but it is harder to do so now that the platform is no longer open source. If the explanation for why the platform is no longer open source were internally consistent, that would at least make things less confusing.

Sincerely,
-Karl

[d3netxer]

+1 Karl

[strk]

+1 Karl

[glezos]

Writing this 2.5 years after the original comment. Wow, time flies, doesn't it.

There's a core decision to keep some parts of the Transifex.com code-base non open-source. There have always been non open-source components, since day 1. Here are a few examples that come into mind right now:

• The distinctive design, look-and-feel of Transifex.com
• Paid subscriptions, quota management of accounts. Notification system related to these.
• Ordering professional translations from external agencies. Features to work with your own professional agencies inside Transifex. Agency dashboards, analytics for SLAs. Translation Memory leverage groups.
• Integrations with other internal services to our company such as sales, marketing, support and other systems.
• Deep analytics and business intelligence to track the success path of users, used to improve the user experience. Internal dashboards.
• Infrastructure integrations with services such as Rackspace Cloud, Amazon Redshift, New Relic etc.
• Built-in referral program with subscription discount
• Delivery component of Transifex Live (CDN) and analytics

There are lots of reasons to keep these components non open-source. It makes sense for us for all kind of reasons, including engineering, operations and business.

In the beginning, when the number of the components were a couple and the codebase was small, we were able to maintain a working open-source repository next to the core one which included the above. After a while, it was very hard to keep maintaining this split and we chose to focus our efforts in other parts.

The truth is, another company might have made the choice to search for the resources somehow to continue maintaining both repos. Maybe that company would have succeeded in doing so, or maybe it would have failed and closed down.

I understand that some of the above disappoint some of you. There are other options. If having the ability to host your own translation system is a blocker to you, we recommend using Pootle or Weblate. Hundreds of projects and companies are using them successfully.

In the meantime, we're committed to continue offering Transifex for free to open-source projects.

[kfogel]

Thanks, @glezos. I think you might be mostly answering a different question to the ones raised (at least the ones raised in recent comments). The point I was making was that it's better for everyone if Transifex is up-front about its reasons. I wasn't arguing with going closed-source as a business decision, I was just saying that if it is a business decision to call it a business decision. The original reasoning given in this ticket didn't really make sense -- and was different from the reasoning you give above :-).

You don't address the question about the patent.

[strypey]

@kfogel Maybe the Transifex commitment to "open source" was always a commitment to the GH model of "open source"? Keep the really significant stuff proprietary, to allow user lock-in (instead of "like-in"), but release all the trivial code that gaffer tapes it all together, so you can leverage the unpaid work of developers in the community to patch your sloppy, prototype code for you, and attract priceless unpaid promotion work from the community, who are always willing to give the benefit of the doubt to new projects (Qwant is a more recent example of this). It's a cynical, extractive model (one people like me and Red Hat have criticized as "open core" although use of this phrase is being discouraged in some quarters), and although encouraging greater use of strong copyleft licenses makes it harder to get away with, if the company does a Canonical and uses Contributor License Agreements to claim any and all rights to engage in "proprietary relicensing", they can still use work donated to a free code project in proprietary products, with or without releasing that code in a free code version.

Just to be clear, I'm not opposed to "selling exceptions" to copyleft, where it means redirecting money into funding free cod dev that would otherwise be spent licensing proprietary software (the Commons Management Agreement that X-Wiki Labs use for this seems legit). I also think there are cases where proprietary relicensing is done is that spirit - GitLab seem pretty genuine in their motives and regularly move code from their EE to their CE in response to developer feedback) - so it's not a cut-and-dried thing. Maybe Transifex started out planning to be like GitLab, but their management got hijacked by some business consultant who doesn't understand the political economy of peer production, and just assumes that making the source code into secret sauce ("controlling the IP") magically makes it more profitable?

AlternativesTo has a list of open source replacements for Transifex. It would be useful to gather feedback from everyone who's evaluated any of them, or any others missing from the list, about which one are completely free code stacks, and which ones are free code gaffer tape wrapped around proprietary business logic.