The reason why we support open source projects is that PhraseApp itself would never exist without open source software: Our cloud service is based on Ruby-on-Rails, we use plenty of different open source projects such as jQuery and Redis in our application and open source-friendly tools like code climate and Travis-ci help us in developing and maintaining our code base. We are passionate developers and we deeply appreciate the work of our colleagues worldwide and the concept of open source. The open source community adds a huge value to our own translation management software and we feel responsible for creating innovation and progressive technology.
As a logical consequence we want to give back to the community and share our first product PhraseApp by offering our service for free to open source projects. In return our cloud-service benefits from the qualified feedback we get from the developers that implement PhraseApp as a translation management software. It helps us to get better continuously.
Are you too considering to make your software open source? What are your concerns? Share them with us by writing to pcquest@cybermedia.co.in.
---------------------------------------
`The Benefit We Get by Making Our Product Open Source is Increased Adoption'
Josep Arroyo, VP of Analytic Solutions, Actuate and Sandip Sharma, Head of Operations - India, Actuate share the hows and whys about making their own product open source
Please state the quantifiable benefits obtained by making Eclipse BIRT's
(BI & Reporting Tool) run-time engine open source.
Our vision behind BIRT is that we want more and more developers and project members to adopt this technology. If they have smaller, non-mission-critical projects, they can adopt our open source platform, which provides similar functionality as Crystal Reports at no cost at all. The benefit to us is that we can increase the adoption of our product. Even commercial customers can benefit by instantly taking advantage of the open source reporting tools available in Eclipse BIRT. Because of our licensing model, a third party is free to adopt our open source product for use in it's own without owing us any royalty.
How are the challenges of documentation and collaboration solved in such a large group of developers?
We have a huge community of more than two million developers and we highly appreciate the work they do. The BIRT Exchange community (website) is closely monitored by BIRT evangelists, who are product engineers answering user questions, conducting webinars, etc, thus making it an actively managed community. 95% of what goes into BIRT is closely monitored by the team.
What steps are being taken in order to maintain adherence to standards in such an open source project?
There are competing tools available in the market that are end-to-end open source. However, we have been very cautious not to make our deployment engine/server open-source, which is where many companies face issues. There are no plans even further down the line to make Actuate BIRT open source. We have a team of developers which focuses on what goes in to the project. Our team of 80 engineers identifies useful functionality that is contributed from the community (not necessarily limited to code/patches), cleanses the sources, performs QA activities, etc. and then incorporates these into the commercial version. Even if 10% of the community inputs get carried forward to our commercial product, it is feasible for us.