Scarab is designed by Collabnet developers, and developers of Turbine, and at one time was even official bugtracking system of ASF. Developers of Turbine had an idea to reorganize framework with the use of service architecture based on Avalon containers. The new version was to be Turbine 3. And they decided to use the Scarab as a testing ground. As a result, year after year, activity decreased in Turbine, because although the framework was not bad, but but not so good as many modern frameworks. Ultimately, people involved in the development of Turbine 3.0 lost interest and to the turbine and to Scarab (For obvious reasons, ASF abandoned him and he too became Collabnet not needed). But the legacy remains.
Ultimately, by the forces of community the best solutions lay in the basis Turbine 2.4 (which has not yet released). But Scarab was forgotten.
As a result, the architectural Scarab now in a landfill like good ideas. And only through community he is still alive, but all new features are made without understanding the concept of Turbine 3 (because it was not defined), and creates even more junk.
If it made even a dozen such changes, the stability, of an already not high, to be lost.
Scarab quite unique software. At least for me there is no free analogs was found. He focuses not on tracking bugs, but on tracking issues. Problems can be either on demand or request. Adjusted absolutely everything. Scarab allows separate all space by modules and customize (types of problems, fields in problems), each module is a unique way. This enables it to use in a wide range of areas: bugtracking, helpdesk management applications, CRM and so on. And most importantly that combine all of this simultaneously in a single system. All who use Scarab very happy with him, except that he does not develop.
I do not wish that the system would have died. And I shall make every effort to this. What I intend to do:
Priorities (release 1.0)
* To port Scarab at Turbine 2.4. This will lead to the destruction depending on Torque
* Clear debris and a refactoring most functionaly overloaded classes.
* Communicate features which was recently implemented to its logical conclusion Scarab
* Finally there old task to enable relevant search, which is provided by Lucene
* Define XML-RPC API for integration with external programs.
* Change UI. Current critically perceived by users.
Secondary objectives (release 1.1):
* Change ORM. If by that time will be ready more or less acceptable OXM (Object XML mapper), then ported to the XML: DB or XQuery.
* Realise integration with Jabber. Make Jabber tool for discussing applications with simulationosly logging conference talk as comments in issue.
This is the main directions of my activities after passing the diploma.
Friday, February 8, 2008
Thursday, November 22, 2007
Is world need another one artifact tracking system?
The number of systems to track artifacts, whether artifacts in the software or as objects with the real world, is so huge, but when the fall to choose between them is the real headache.
What the problem with this diversity? The problem is that the scope of the kind software vast and diverse, it creates a limitless variety of requirements for the product. No developer is not a challenge to please everyone, he chooses area (sector), the application of their future product and sells it as widely as possible for the microscopic sector. And all would be well, but often somewhat broader area of interest of the microscopic sector. For example IT company wants to use the same system to track bugs and features developed in software, and keep the IT service applications.
The search for a solution satisfying all the requirements are really difficult task. And given the desire not to pay money to keep things, or does not pay, it is often intractable and leads to go on a compromise solution. Or pay third-party organizations for the development or expansion of refinement, and could do worse - refine itself.
In any of the cases cited above, the total cost of ownership of the system increases, while significantly.
And what we propose to the developers of the software. Well, in the first developers can be divided into groups, like the products themselves.
Most of the market of course, the so-called Bug Tracking software. This software mainly confined to the processing of artifacts appearing during software development - Bugs, Improvements, Tasks, etc. It must be said that in this area OpenSource community succeeded most. But it is clear: the majority of the OpenSource bug tracking drafted by the developers own needs, and then became spread. The most frequently encountered of them are now Bugzilla, Trac, Mantis, Flyspray. They are all quite different, so it is difficult to identify the apparent favorite. Despite the focus on one sector most of the popular systems is a unique feature.
One can safely say that at this point in the selection system for tracking artifacts in the software, the choice is in favor of the proprietary system in very rare circumstances: when none of OpenSource system does not meet the requirements, and given their number is not often the case.
Another theme is a tracking system artifacts in the general sense. This includes HelpDesk system, maintaining applications in CRM systems, there is an area of intersection with project management systems. It was in this area to find a compromise solution to a very difficult, as the IT infrastructure of large enterprises highly elaborate and multifaceted. If you are able to do and the introduction of a product, this is a great rarity, or a miracle. Otherwise, the fall to introduce two or even three different systems. And if you want to integrate them, the total cost of ownership of each of them significantly increased.
In this sphere number OpenSource solutions very limited, but it present.
What is the reason for this situation? Market twenty more years, but nothing has changed fundamentally. Something has become easier, something beautiful, but a universal solution not developed. There is not even a good solution in terms of integration. How many people work on projects OpenSource? And over how much commercial? Together, they will be able to develop beyond a universal solution for a period of three months. Yet they all go their route. As a result, we lose money and the enormous quantity of resources.
List and comparative characteristics trackers is Wikipedia http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
And now the question: Do the world need a new one artifacts tracker? And if so which?
What the problem with this diversity? The problem is that the scope of the kind software vast and diverse, it creates a limitless variety of requirements for the product. No developer is not a challenge to please everyone, he chooses area (sector), the application of their future product and sells it as widely as possible for the microscopic sector. And all would be well, but often somewhat broader area of interest of the microscopic sector. For example IT company wants to use the same system to track bugs and features developed in software, and keep the IT service applications.
The search for a solution satisfying all the requirements are really difficult task. And given the desire not to pay money to keep things, or does not pay, it is often intractable and leads to go on a compromise solution. Or pay third-party organizations for the development or expansion of refinement, and could do worse - refine itself.
In any of the cases cited above, the total cost of ownership of the system increases, while significantly.
And what we propose to the developers of the software. Well, in the first developers can be divided into groups, like the products themselves.
Most of the market of course, the so-called Bug Tracking software. This software mainly confined to the processing of artifacts appearing during software development - Bugs, Improvements, Tasks, etc. It must be said that in this area OpenSource community succeeded most. But it is clear: the majority of the OpenSource bug tracking drafted by the developers own needs, and then became spread. The most frequently encountered of them are now Bugzilla, Trac, Mantis, Flyspray. They are all quite different, so it is difficult to identify the apparent favorite. Despite the focus on one sector most of the popular systems is a unique feature.
One can safely say that at this point in the selection system for tracking artifacts in the software, the choice is in favor of the proprietary system in very rare circumstances: when none of OpenSource system does not meet the requirements, and given their number is not often the case.
Another theme is a tracking system artifacts in the general sense. This includes HelpDesk system, maintaining applications in CRM systems, there is an area of intersection with project management systems. It was in this area to find a compromise solution to a very difficult, as the IT infrastructure of large enterprises highly elaborate and multifaceted. If you are able to do and the introduction of a product, this is a great rarity, or a miracle. Otherwise, the fall to introduce two or even three different systems. And if you want to integrate them, the total cost of ownership of each of them significantly increased.
In this sphere number OpenSource solutions very limited, but it present.
What is the reason for this situation? Market twenty more years, but nothing has changed fundamentally. Something has become easier, something beautiful, but a universal solution not developed. There is not even a good solution in terms of integration. How many people work on projects OpenSource? And over how much commercial? Together, they will be able to develop beyond a universal solution for a period of three months. Yet they all go their route. As a result, we lose money and the enormous quantity of resources.
List and comparative characteristics trackers is Wikipedia http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
And now the question: Do the world need a new one artifacts tracker? And if so which?
Wednesday, August 15, 2007
Subscribe to:
Posts (Atom)