When we are about to try a new web application we ask experts, who are familiar with it, what would they recommend us to use, for example, which database backend, which platform, and many more. That's what this chapter will try to do, it will help you learn what options are available and which one fits your needs better.
In this chapter you will also find a very short description of the Redmine interface. It's described in short because I believe it is easy to learn. You will be able to play with it more in the next chapters where we'll discuss how to install and use Redmine. So why this chapter should be of interest to you? The power of Redmine is in its components; some components influence performance, others influence functionality. I'm quite sure that even experienced users will discover new options in this chapter and may decide to switch to or utilize them.
In this chapter, we will cover the following topics:
If you search for a free project management tool most likely you will end up with Redmine. This is an open source Ruby on Rails web application, which can be considered to be the de facto flagship of project management solutions in the open source world. It supports all you need for effective project management: member roles, permissions management based on roles, Gantt charts, scheduling, calendar, roadmap, versions management, documents management, news delivery, files directory, activity view, and more. With third-party extensions, you may also get invoice management, Scrum backlogs, Kanban board, burndown charts, and more. But it's not only a matter of project management.
No one can tell whether Redmine is more a project management tool or an issue tracker. Ideally, a good issue tracker must have some project management features. In Redmine these two components are combined flawlessly. But what makes it a perfect issue tracking application is the fully-configurable workflow, which lets defining issue status change permissions for each role and tracker (issue type). As an issue tracker, Redmine also supports such essential features as priorities, sub issues, watching, comments, custom fields, listing filters, and more. Anyone who has ever worked in a team understands the importance of project documentation. For this purpose, many teams establish Wiki sites. Redmine ships with its own per-project Wiki system supporting the Textile markup syntax and source code syntax highlighting. The staggering thing is that this Wiki syntax is supported all over the Redmine that is in issue descriptions, comments, news, and so on. The syntax also allows you to have cross links to other issues and projects.
For public projects support, Redmine comes with a simple bulletin board module, which allows you to have as many forums as you need. Each forum can have an arbitrary number of threads. Forums and threads can be also watched.
Having read the above paragraphs one may think that the only missing feature for making Redmine host one's projects is some support for version control systems. But such support is also available. Redmine can be used as a repository source code browser. The repository component also integrates flawlessly into other Redmine components such as issue tracker and Wiki. For example, an issue can have list of revisions related to it, a Wiki page can link to a revision, a commit, a source file, and more. With some additional extensions, Redmine also can be turned into a repository manager or even play like Github. The list of supported version control systems is also impressive. They are Subversion (SVN), Git, CVS, Mercurial, Bazaar, and Darcs.
All the things mentioned above make Redmine a perfect application for project hosting. Many individuals and organizations use it for this purpose. But it's not limited to a single project – it is multiproject and each project can have subprojects to any nesting level. Many companies utilize Redmine's collaborative capabilities for forge or labs sites. However, it is not even limited to software development. Other companies use Redmine for customer support, order fulfillment, task management, document management, and more.
I cannot describe Redmine without mentioning the people who created this fabulous software. As soon as you open Redmine, you see the name of its primary author at the bottom of each page (near the copyright section), Jean-Philippe Lang. A huge contribution to Redmine was also made by Eric Davis who then forked Redmine into ChiliProject.
The previous topic makes Redmine sound like some all-in-one software. To some extent it is. It was the evolution of Redmine that made it look like this. It is extremely popular these days and that's why it constantly gets new features. But what makes it so popular?
Having first seen Redmine I got the impression that it was a very easy-to-use and friendly application. It is not overloaded with design and UI elements and everything seems to be in its place. This makes users get used to Redmine and like it on first sight. The very first time I saw Redmine I also thought that perhaps it was too limited for my needs mainly because it looked too simple. Both impressions were wrong; it's not an easy-to-use software and it's not limited. The easiness of the look and feel however does its job. If you need only basic features you are ready to use Redmine right after you have seen it for the first time. When you need more advanced features you need to spend some time learning them. That's the main thing that makes Redmine so popular I believe.
The right tools are built with the right technologies. What make Redmine so "right" are Ruby and Rails. Ruby is known to be perhaps the most modern metaprogramming truly object-oriented language. This programming language is very flexible and is considered to allow building powerful applications fast and easily. All this can be said about Redmine. This all can be said about Ruby-on-Rails as well. Rails is a web framework similar to Symfony and Zend Framework but unlike the others it is the de facto standard for Ruby. Treat Rails as a construction set for building web services like Redmine. The names are so closely associated that many people believe they are about the same language. Ruby-on-Rails also became the source of inspiration for many frameworks and libraries such as CakePHP and Grails. Redmine is built on these technologies and this is the thing that makes it so good.
Of course, you can wonder what exactly is in Ruby-on-Rails that makes it good? The first thing is that Ruby (and therefore Ruby-on-Rails) supports metaprogramming. It's the technique which allows an application to modify its code (that is itself) at runtime. This means that there is almost nothing in Redmine that cannot be altered programmatically. Usually API of an application is limited to some functionality but there are no limitations in Ruby thanks to metaprogramming. What a good feature for plugin API, isn't it? The second thing is that Ruby-on-Rails establishes plugin API, which is used to develop Rails plugins called engines. So as you see Redmine does not actually need to provide plugin API to be extendable but it does. Redmine plugin API is built on top of the Rails engine API.
Thereby we come to the next thing, which makes Redmine so popular—its plugins. If you are familiar with Ruby and Ruby-on-Rails, you need to learn a little to start developing Redmine plugins. Taking into account that Ruby-on-Rails is very popular nowadays, Redmine has a huge amount of potential developers. Therefore it has a large variety of plugins. With its plugins you can even turn Redmine into a CRM or help desk. Some of the plugins will be reviewed in Chapter 10, Plugins and Themes.
Note
The known issue is (at least partial) Redmine versions incompatibility. Redmine plugin API used to be changed from version to version without good backwards compatibility. It's even more critical as many plugins use metaprogramming for altering non-API (core) functionality. But in fact it's impossible to preserve full backwards compatibility in such cases. The same compatibility issue affects the Rails API that is especially seen in Redmine 2.0, which switches from Rails 2 to Rails 3. Hence, when selecting a plugin you should always check if it is compatible with the Redmine version you are using.
And last but not the least important benefits are that Redmine is cross-platform open source and freely available. Open source code and GPL license makes any modification possible. Nothing limits you in making Redmine better fit your needs.
It's always better to meet than to only hear about. I cannot imagine a reader who is familiar with Redmine but has never seen it. So let's start with checking the Redmine interface.
As mentioned earlier, Redmine has an easy-to-use and simple interface. The following screenshot shows its Home page:
On the top-left of the page, we have the global menu (Home, My page, and so on). To the right-hand side of the page, we have the account menu (Logged in as). The blue area below these menus contains the site title. And finally the content area contains site introduction, recent news for all projects and recent projects.
Actually any page in Redmine can be either a global page (the previous screenshot) or a project page:
This is the start page for a project or the project home page. Most of the time when working with Redmine, you will be interacting with project pages. The blue top area on a project page contains the project title. The project menu is displayed below the title. The project home page contains a description of the project, issues summary, members summary, and the latest news about the project. Most project pages also have the sidebar with contextual information, such as links and forms.
As one of the primary features of Redmine is issue tracking, let's check the issue list:
As you see the layout is quite simple and friendly. Collapsible boxes such as Filters and Options are used all over Redmine to hide rarely used elements. The order of issues in the issues-listing table can be changed by clicking on a header.
The following screenshot shows how an issue page looks:
In the top-right corner of the content area we see the contextual menu, which is duplicated at the bottom of the page. A similar type of menu is used for other Redmine objects such as projects, Wiki pages, and more. The big yellowish box contains issue details. Below this box, there is the changes' history.
Another UI element, which is intensively used in Redmine is the tabular menu. Such a menu can be found, for example, in the project settings:
Here we also see another UI element, which is widely used in Redmine - the Wiki syntax enabled text area.
The following screenshot shows how administration settings are implemented in a similar way:
This is another global page (similar to Home). Administration sections are available on the sidebar. Currently, we are in the Settings section, which also utilizes a tabular menu. On the General tab of the Settings section, we see Wiki-enabled Welcome text field.
This was a short walk through the Redmine interface to let you get used to it and understand its basic concepts. I hope you see that it is easy to use. We will review the interface in detail in subsequent chapters.
Redmine can be used with MySQL, PostgreSQL, or SQLite database backends (actually the same backends that are natively supported by Ruby-on-Rails). But which of those should you use? It's perhaps too important a question to be ignored in this book. No, I'm not going to praise one of the databases or criticize another (it's out of scope here) but I'll cover things you should consider when choosing a database backend.
In its Installation Guide in the Database section (http://www.redmine.org/projects/redmine/wiki/RedmineInstall#Database) at the time of writing this book, authors of Redmine added (recommended) to the right of MySQL. Let's try to understand why they recommended this backend.
Having worked with Redmine for a long time I noticed that most users use it with MySQL. It does not matter why they choose it but this means that Redmine has been tested better with this database backend. As long as plugins may use SQL directly (that is without using Rails SQL query builder) this argument becomes even more important. Also I'm sure there are plugins which have been never tested with other database backends.
If you are seeking a reliable source on what database is faster with Redmine, you can check Redmine build logs at http://www.redmine.org/builds/index.html. These logs contain results of tests for different versions of Ruby and different databases. Thus at the moment of writing this topic the latest revision r9739 in the latest stable branch 2.0-stable contained the following timings (showing only ruby-1.9.3-p194):
|
mysql |
postgresql |
sqlite3 | |
|---|---|---|---|
|
Tests run 1 |
304.131903s |
320.018676s |
276.440358s |
|
Tests run 2 |
308.206684s |
311.683513s |
283.817843s |
|
Tests run 3 |
112.832042s |
105.113524s |
94.457021s |
|
Total |
725.170629s |
736.815713s |
654.715222s |
According to these data, SQLite is fastest and PostgreSQL is slowest. You can check new data or take several revisions into account to make sure.
You can ask: Why not SQLite then, if it's the fastest? SQLite has scalability issues (you can't put it on a separate server) and can potentially have problems with concurrent access. So, MySQL looks to be the optimal backend.
Good readability helps achieving perception. Rich formatting is very important for issue tracking software as it allows you to distinguish and highlight more important things thus drawing special attention to them. In Redmine, rich formatting is done using Textile syntaxes, which is supported almost in every text area. In addition, Redmine provides formatter API, which means that the default Textile formatter can be replaced.
There were attempts to add different syntaxes to Redmine Wiki but the only successful and still active non-native Wiki syntax plugin is the Markdown Redcarpet plugin (https://github.com/alminium/redmine_redcarpet_formatter). This plugin replaced the default Redmine formatter with the Markdown formatter, which uses the Redcarpet library. This is the same library that is used by Github. Therefore the syntax provided with the Redcarpet plugin is compatible with Github's Markdown syntax.
If you asked what formatter I recommend, I would answer Textile. The Textile formatter is native, well supported, and well tested. However, when choosing a formatter you should consider your audience; if your audience is mostly Github users you should perhaps try Markdown but still remember that the majority of Redmine installations use Textile and users may expect your Redmine to use Textile as well.
But let's not be too verbose and compare basic rules of these syntaxes:
|
Textile |
Markdown | |
|---|---|---|
|
Bold text |
|
|
|
Italic text |
|
|
|
Underline text |
|
|
|
Inline code |
|
|
|
Preformatted text |
|
Text which starts with spaces |
|
Syntax highlighting |
|
|
|
Bullet List |
|
|
|
|
| |
|
Numbered list |
|
|
|
|
| |
|
Headings |
|
|
|
|
| |
|
|
| |
|
|
| |
|
Links"Anchor":http://link |
| |
|
Images |
|
|
|
Tables |
|
|
|
|
| |
|
|
Source Control Management (SCM) is better known as Revision Control Management. Revision control systems currently supported by Redmine include Subversion (SVN), Git, Mercurial, Bazaar, Darcs and CVS.
As mentioned, Redmine integrates SCMs nicely using them not just as source code readers but making more use of them. In Redmine, we can do the following: Associate a revision with issues (having revisions listed on issue pages). Automatically close an issue and/or change its done ratio when an appropriate commit has been made. Use Wiki syntax in commit messages. Refer a revision, a commit, or a file from a Wiki syntax powered content, which can be a Wiki page, an issue description, a project description, or a forum message and much more
But all this makes Redmine a source code browser not a SCM manager (that can be done with plugins however). So why is choosing the right SCM so important?
Unless you are fine with having SCM and Redmine integrated visually most likely you will want a deeper integration when you know the options. Three levels of Redmine and SCM integration can be distinguished as follows:
Redmine as a source code browser
Redmine as a SCM authenticator
Redmine as a SCM manager
The basic browser level requires SCM clients to be installed on the same server Redmine is running on so you may want to use only some of the supported SCMs. Also the basic support of SCMs is not equal: revision graph (similar to one on Github) is supported only for Git and Mercurial, however, these two SCMs can be only local (repositories should be on the same server, where the Redmine is).
Redmine comes with Redmine.pm—a Perl module for Apache web server—which can be used to authenticate Subversion and Git users against Redmine. If the Redmine.pm tool has been integrated, you can control who has access to project Subversion/Git repository and what kind of access (read and/or write) they have by simply managing project members (and roles). Something similar (with additional changes made to Redmine and/or system) can be done for Mercurial and Bazaar. Nevertheless Subversion and Git SCMs are best supported by Redmine.pm and their support is out of the box. Most likely you will have problems configuring other SCMs to authenticate against Redmine.
The only missing functionality for Redmine to become a full-featured SCM manager is the ability to create repositories. And such functionality also comes with Redmine and is provided by the reposman.rb command-line tool. This tool supports Subversion, Darcs, Mercurial, Bazaar, and Git (all except CVS). The problem is that in order for it to work you need to create a cron job executing it periodically. Luckily alternative solutions exist and are provided by third-party plugins such as SCM Creator, Redmine Git Hosting, and Redmine Gitosis.
When choosing SCM, you should also consider your requirements, your experience, preferences of your team or audience, easiness or complexity of use and so on. However, the best integratable SCMs seem to be Subversion and Git.
Redmine as a Ruby-on-Rails web application should be run under a web server. This can be an independent web server such as Apache, Nginx, or Lighttpd running Ruby-on-Rails using either Passenger, FastCGI, or a dedicated Ruby web server such as Unicorn or Thin.
A big options list, isn't it? Actually these are not all the possible options. Redmine can also be used with JRuby under a Java virtual machine, can be run under standalone Passenger, under Mongrel, under WEBrick, and more. But the above options were chosen by practical use and, therefore, are most commonly used. So we review only them here. They can be divided into three categories:
Dedicated Ruby web server
Dedicated Ruby web server plus for example, Nginx as a load balancer
Separate web server with for example, Passenger module
Ruby often gets compared to PHP but actually these technologies are very different. For a PHP guy, which I am as well, using a web server written in Ruby for running a Ruby application can be weird. But in fact Ruby, like Java, also runs under a virtual machine. Therefore, for example, Apache in order to run a Ruby application needs to run a Ruby virtual machine as well so in total these are at least three processes: a web server, an application server, and an application itself. For this reason running a Ruby application under a Ruby server seems to be reasonable because in this case we get only two processes namely an application server and an application.
The lack of good multithreading support is a known problem of all Ruby virtual machines. This is the main reason why when running Ruby applications on production they usually use a Ruby application server in conjunction with another web server. As Ruby does not play well with multiple connections they run many instances of Ruby application server and use for example, Apache as a load balancer for forwarding requests to those instances and as a web server for giving static content (images, css files, and so on). The most documented option for this category is Apache plus Mongrel, the combination which, for example, was used by Twitter before the company moved first to Unicorn and then to Java. But the best combination, according to many benchmark results, is Nginx plus Thin or Unicorn.
But in fact this configuration uses not only a web server and an application server but also a load balancer. A web server needs to support the reverse proxy mode to be able to act as a load balancer. For Apache, this mode can be provided by mod_proxy, Nginx, and Lighttpd have built-in proxies. In addition, a good idea is to use some software for monitoring Unicorn/Thin instances, for example, onit.
You perhaps got the feeling that the just discussed category is for advanced usage and for high loaded services? Yes, it is in a way. The most commonly used, easy-to-install and best documented is the third category: a web server running a Ruby application using the Passenger module (also known as mod_rails) or the FastCGI module. The Passenger module is in fact another Ruby application server. The difference between it and Unicorn/Thin is that it usually runs as a module of a web server and not as a standalone server (while the last is possible). The problem with the Passenger is that it does not work with Windows. Also, the Passenger module is not available for Lighttpd. Thus, Lighttpd uses FastCGI for running Redmine instead. FastCGI, which is actually a protocol name, can be also used under Apache and Nginx.
However, the Passenger is more popular. It is used, for example, by BitNami Redmine stack and TurnKey Redmine appliances (systems for easy deployment of Redmine). In addition it is suitable not only for small and middle-sized websites but can be used for high-loaded web services as well. Thus, for example, Ruby-on-Rails framework recommends using Passenger in flavor of other options (http://rubyonrails.org/deploy).
When run under a web server the Passenger creates at least two processes—itself and an application. This can be a problem if it is used on cheap OpenVZ powered VPS hosting where memory amount used by an application is very critical. This is where FastCGI helps: when run with FastCGI Redmine occupies at least one process (application).
In case you still don't feel sure about which option to choose, let's summarize:
If you plan to use Redmine for a heavy-loaded forge site you should think about using Nginx with Unicorn/Thin and possibly HAProxy.
For all other cases or if you are just unsure go with Apache or Nginx and the Passenger module.
While choosing you should also consider your other requirements and services you plan to run on the same server. For example, you will definitely need Apache if you plan to use Redmine.pm for authenticating Subversion/Git users against Redmine.
In the open source world, a good project can't just die or become worse because such projects always have a community ready to support it or take it over. If something goes wrong with a project its community can always make a fork. But the reason for making a fork can be just a wish to make the project better. Usually the appearance of a fork also divides the community, however, this does not make the fork or the project worse. In fact with the fork the original project gets a solid competitor—itself. And competition is what makes project developers strive for the best.
The history of open source knows many examples of forking and rewriting software what ends with the appearance of a new, better, or just different project. We do not need to search for such examples: Joomla was forked from Mambo, Gforge from SourceForge, X.Org from XFree86, Apache from NCSA, LibreOffice from OpenOffice.org, and many more.
You perhaps noticed that every page of Redmine contains a line Powered by Redmine © 2006-2012 Jean-Philippe Lang at the bottom. Jean-Philippe is the author of Redmine and its project manager but there were more people involved in this great project and one of them was Eric Davis. In 2011, due to project management concerns and community patches inclusion policy Eric Davis with some other Redmine core developers (most of whom are finnlabs (www.finn.de) employees) forked Redmine into the ChiliProject. This is how forking is explained on the ChiliProject site (https://www.chiliproject.org/projects/chiliproject/wiki/Why_Fork):
However, in the view of some of Redmine's leading developers, the maintenance and evolution of Redmine has not been as predictable and responsive as its developer community is capable of. Integration of community-created patches were too sporadic, lacked a clear methodology, and was interfering with the effectiveness of the Redmine project for its users. Over the past two years, several members of Redmine's community worked to resolve management bottlenecks through clear suggestions and contributions. They also attempted to broaden and open up the development process to more contributors. But efforts via public and private forums to discuss the goals and future direction with the project manager of Redmine failed, as the current project manager did not share these priorities.
A group of developers from the Redmine community has therefore concluded that the only way to ensure continued, sustained and stable development of our favorite project management solution is to fork it. We, long-standing community members and contributors, pledge to uphold the ideals of Free and Open Source Software ethics, governance and development practices in order to produce a reliable project management system released under the name of ChiliProject in February 2011.
Luckily at the moment Redmine and ChiliProject do not differ much so almost everything written in this book applies to ChiliProject as well.
So which one to choose? Let's discuss the difference now:
Of course, Redmine is older. It has been proven to live, to survive and be successful, its developers were active over five years and continue to be (besides Jean-Philippe there are Toshi Maruyama, Etienne Massip and others), it's stable.
Redmine has a bigger community than ChiliProject. But this does not mean that ChiliProject is worse though, most users have not moved to ChiliProject because they see no reason. Such a big community is mainly due to age. However, this means that most likely you will get support for Redmine faster.
Redmine comes in Bitnami, Turnkey, it is available in official repositories of Debian and Ubuntu, it is available for hosting at Plan.io, HostedRedmine and more. But again it's mainly due to its age.
Redmine does not get changed much, it feels like a well supported software with major changes coming rarely (except 2.0.x which moved to Rails 3 but it was a developers' headache, not a users'). By changes, here I meant functionality and UI changes, which required users to update their third-party tools or get used to.
ChiliProject, on the contrary, introduces major changes with each major release. It feels like ChiliProject developers finally have a possibility to implement things they've wanted for a long time. However, these changes add much work for developers of third-party tools and many things should be learned by users.
ChiliProject promotes openness of development process and readiness for contribution. If you or your organization plan to modify the core or you just feel you or your organization can do this and you are ready to share your modifications, you should consider using ChiliProject. To some extent ChiliProject is for enthusiasts and advanced users.
ChiliProject lacks a good plugins registry which is available for Redmine, it has only a plugins compatibility list. However, Redmine plugins registry is far from being perfect (for example, it's incomplete and lacks some search capabilities).
The situation with themes is even worse: Redmine has many themes but they are not compatible with ChiliProject anymore since Version 3.x of the latter. ChiliProject 3.x does not seem to have any third-party themes available (ChiliProject prior to 3.0 worked fine with Redmine themes).
Having mentioned theme changes in ChiliProject 3, let's see what its new default theme looks like:
Some up-to-date information about differences in Redmine and ChiliProject is also available on the website of the latter: https://www.chiliproject.org/projects/chiliproject/wiki/Differences_Between_Chiliproject_and_Redmine.
You might expect features comparison in this topic. But theoretically features of Redmine and ChiliProject can be merged relatively easily into each other. So any features comparison here can become outdated when this book comes into your hands. So instead I decided to review different approaches these projects are taking. I hope this information is enough for you to decide.
Overall, ChiliProject seems to be in "transitional" period when its features, look and feel, design, and so on are changed and at the end of this period ChiliProject will turn into a completely different project management solution. Maybe it worth waiting for this period to finish but maybe it's worth helping the ChiliProject guys to move.
On the other hand, Redmine is a proven, stable solution, well-known, and well-documented.
In most cases everyone uses the most recent version of an application, which is 2.2.x in the case of Redmine. But there can be a choice. Thus, some stable Linux distributions come with older Redmine versions. Should you stick to that version or should you install the recent one which is more complex and assumes further manual checks for updates and doing multiple manual migrations? Besides, what if your organization uses a hardly modified copy of Redmine and therefore sticks to a particular version? Should you allocate resources for a hard migration? To answer such questions you should know a few things about those versions such as what do you lose, what will you get and so on. In this topic, we will review primary features introduced by some recent versions of Redmine and ChiliProject.
At the time of writing this topic the recent version was 2.2.x. We will review all major versions down to 1.4.x.
2.2.x
This version comes with the following noticeable features:
Support for private comments in issues
Working days configuration
2.1.x
This version upgrades Redmine to Rails 3.2.x, which switches from Prototype to jQuery. This also requires developers to update their third-party tools. Besides, the version comes with the following features:
Ability to require issue fields or make issue fields read-only per status, tracker, and role
Support for subforums
Ability to close (freeze) projects
The Version 2.0.x is the upgrade of Redmine to Rails 3.1.x. It was released along with Version 1.4.x that is we got two stable versions at the same time (nothing like this ever happened before)! This version was released mainly for developers so they could upgrade their third-party tools.
1.4.x
This version includes the following new noticeable features:
Basically, due to migration to Rails 3 and, therefore, huge changes in API at the time of writing this book, not all Redmine plugins have been ported to Redmine 2.x.x yet.
The most recent version of ChiliProject at the time of writing this topic is 3.x.x. Unlike previous versions, this version ships with some new interesting features. Earlier there were versions 1.x.x and 2.x.x but only the latter was bringing a really new project.
What would be Redmine without many people contributing to it? Most likely it would not exist at all. Any contribution is very important for a free open source project, an active and passionate community is what makes such projects good.
Hearing about contributing to a free open source project most people assume some development but there are manu more areas where you can help. For example, this book helps Redmine by spreading information about it, teaching how to use it and demonstrating its abilities. You help Redmine by purchasing this book not only because you become a potential fan of this project but also because Packt Publishing, the company which publishes this book, will pay a royalty to Redmine.
Let's discuss how else can you can help Redmine:
As it has been already mentioned let's start with development: If you are a developer you can help by contributing code or patches to Redmine. To do this you should know Ruby and Ruby-on-Rails but if you know Perl you can still help by improving
Redmine.pm. You can help even more if you know HTML and/or JavaScript because these technologies are intensively used by Redmine and may need improving. If you know neither of the above technologies you can still help by for example, developing a REST API client library for Redmine using technologies you know.Some links regarding development for Redmine:
General information: http://www.redmine.org/projects/redmine/wiki/Contribute
Subversion repository: http://redmine.rubyforge.org/svn/
Git repository: https://github.com/redmine/redmine
If you are a designer you can make new themes for Redmine. This is an extremely important area as a good theme attracts more users.
You can write articles, blog posts, tutorials, improve source code documentation (which uses RDoc), and more. You can do this in English or any other language.
Regarding other languages: You can also translate Redmine, its official or unofficial tutorials and so on, into other languages.
If you are just a user or are going to become a user, do not neglect to report bugs or to suggest new features. If you are not sure that something is a bug still open a discussion on the Redmine forum and ask the community. Many bugs are hard to find and not many people report them.
And last: You can show your support for Redmine by making a donation.
In a similar way you can help not only Redmine but also its fork ChiliProject and many free open source plugins for Redmine.
The goal of this chapter was to familiarize you with Redmine and get you ready to dig deeper into this web application. Therefore we have reviewed not only advantages and the interface of Redmine but also have checked its installation components. We have also discussed ChiliProject as it's a community fork of Redmine and it's important to know about it if you become (or have become) a member of the Redmine community.
I tried to share as much knowledge about Redmine, its fork and its installation components as possible so you could understand them better, learn what options you have and would be able to choose the right option. Still remember that usually the best option is the one which is used by most users so if you choose an uncommon option you should be sure about the reasons for doing this.
The knowledge you have gained reading this chapter will help you in the next chapter as you will need to decide what components you will use for installation. However, the next chapter covers only common options. Anyway if you chose other options it's still worth reading the next chapter to see how the installation is done.
