news



Open Source Ticketing

Time for another update. I have been updating the comments, but I figured it would be a good idea to do a post. The new code is working well. There have been a few bugs, but generally it is working well. Let me just say it is a 100% improvement over the old code.

We have been using the first release of SimpleTicket for about six months. We have been able to determine what works and what needs improvement. The new version of SimpleTicket addresses many of the shortcomings of the first release from a workflow perspective. From a code perspective the new code conforms to the Ruby on Rails methodology.

The guys are still working on bugs and little edits, but our primary objective is to import six months of data into the new version (we think that will be the best way to bug test the new code) and start testing. Concurrently one of our designers is adding gradients and shadows to the panels.

Finally, the most exciting feature of SimpleTicket is its ability to deliver statistics about our clients to the managers of Architel. We can now have a real-time view into our business - a huge feature of Simpleticket. There is a big shortcoming in our view of the stats; the columns can’t be sorted in ascending or decending order - they are simply in alpha order. I have been told it is very hard to code a solution to this problem. If you have any ideas please post here. Otherwise, we will release without a solution for now. Thanks to our brothers in Paris who did most of the coding on the new version of SimpleTicket - there is light at the end of the tunnel.

.

July 29, 2006 | Trackback |

Tags: SimpleTicket , simpleticket , opensource , troubleticket , gpl | Bookmark on del.icio.us | Digg It



8 Responses to “Open Source Ticketing”

  1. Frank Says:

    I am good friends with Kate and Peter and it really pisses me off seeing how you guys have ignored their needs. Before going out and just coding whatever you want you should consult the community. Kate and Peter have very specific needs and the wireframes and the descriptions detailed in this blog don’t meet their requirements. How do you expect them to use simpleticket if you don’t get their buyin? We are outraged that you would pay programmers to build a ticketing system for your own company and not contribute to the open source community.

  2. Fred Says:

    Okay, you guys are really over the top. We developed SimpleTicket for Architel’s needs. That has been the stated purpose from the beginning. We released the code that we use internally six months ago. Kate created her own branch of the code and made some very helpful contributions (some have been incorporated in the new version of SimpleTicket). Peter contributed to Kate’s branch, but none of his code was topical to our project (it was relative to his own needs). Our primary objective during the first 90 days after release was to resolve bugs and security issues. The last 90 days were spent refactoring the code (really rewriting most of it).

    At the end of the day SimpleTicket was written for Architel. If other companies can use our code or a “branch” of our code we are happy to contribute our effort to their cause - absolutely free. If Peter and Kate need certain functionality or features I suggest they take the code and modify it. It is not our responsibility to cater to the needs of Kate or Peter. To suggest that you are “pissed off” or “outraged” is simply crazy. Please go away and complain to another project. I am sure there are plenty that would love a few dissenters!

  3. nowave Says:

    I’m sure no-one cares what “Kate” or “Peter” think. If they truly did buy in to the open source development model, then they don’t NEED Architel from the moment the 0.1 SVN checkin was released. The whole point of an open source development model is, “If you don’t like it, modify it to a point that fits your needs, then re-release it.” How hard is that to understand?

    It really pisses me off when people, that I call “technology consumers” get into the OSS market. They entertain the notion that they have somehow paid someone to develop this software, and that their bugs and/or feature requests should be resolved immediately. This isn’t the case. The case, in this instance, is that a private company has released their own internal ticketing system for the community to contribute to and modify. They will neither sink nor swim with your success nor failure. Use and ignore as you please, PLEASE.

    My personal opinion is that people like “Kate” and “Peter” should just stop trying to live on the bleeding edge. This is an area for a people for a certain level of skill and risk acceptance. This is not a value judgement (not matter how much I just want to tell you to f* off). I honestly feel you should wait and try to ingest this project when it is in a more mature state. You will be much more happy with the result and the resultant community that may build from that release.

    Thank you for listening to my rant, and please, think more carefully about the open source projects you choose to dip your toes into. They are often very good, but they are very rarely “drop-in” solutions.

    Good luck with your endeavors.

  4. satadru Says:

    I, for one, welcome our new Architel overlords while we wait for a code drop…

  5. masukomi Says:

    I (Kate) don’t actually care what architel does with this new version. As Fred said, they’re not writing it for us. I’m not outraged at all. They’re writing a ticket system for their internal needs. So what? I’m glad they finally got someone on staff to code it. They needed that. The lack of internal work/guidence was one of the biggest problems with the first iteration.

    And, as Architel said when the inital version imploded, we’re free to take the original version we were working on and do whatever we want with it, including release it, as long as we don’t call it SimpleTicket. My contributions were just that, “contributions”. I don’t regret them, and accepted from the beginning that they may not be used. The only thing i do regret is that the project imploded.

    As for not living on the bleeding egde, I wasn’t a “consumer” of the project, whining that i didn’t get my money’s worth and neither was Peter. We were it’s main developers for a while, and were probably more aware of it’s risks than anyone at Architel (seeing as it’s original creator left Architel). We had no problem “ingesting” it. And i was perfectly happy with the code as it was. It was rough and had lots of issues but i knew that when i started in on it.

    I may have issues with Architel’s handling of the initial project and the fact that the keep promoting the Open Source aspects of project when I can’t seem to find anything “open” about the current version (athough i do believe and applaud that they well release the code again when they’re ready). Please correct me if I’m wrong here. But, regardless, this is Architel’s baby and as long as it’s internal they should be beholden to nobody but themselves. Even if they do release it they only really become beholden to the community at large if they ask it to participate.

    Another viable option for them is to just make the source available and not participate in any community that may or may not try to form around it. If they do that they can still do whatever they want without regard to the rest of the world. And while that would superficially seem wrong or bad, even just releasing the code into the wild, and doing nothing else, is still a contribution to the world at large that I, for one, appreciate from any company.

    So, yay Architel for having the intelligence to rewrite it (mostly) from scratch instead of trying to continue with the old codebase. Yay architel for getting something they seem to be happy with. I’m glad some of my code contributions helped them. I wish the process was open but hey, it’s not my project. I hope they’ve had success with the plugin system they were plannig on writing and am interested to see what they’ve come up with.

    I harbor no ill will towards Architel and only hope that they have a better grasp of how the open source process works when they release the next version so that more parties can benefit from it and community issues will be better handled.

  6. Fred Says:

    Why do you say, “I may have issues with Architel’s handling of the initial project and the fact that the keep promoting the Open Source aspects of project when I can’t seem to find anything “openâ€? about the current version”?

    The definition of an open source project is the fact that you RELEASE the code using an open source license such as the GPL, not whether or not you accept code from third parties. The OPEN part of the project is the fact that the code is OPEN - not the process. We closed the process of developing the code because we were spending more time talking about the project than actually working on the project. Now we just work on the project (except for responding to your comoments)! Thanks for your kind words, I think the net-net is that we disagree with the definition of what makes an open source project open…

  7. Peter Says:

    For sorting columns of data, check out how dry_scaffold does it. It is pretty slick (not easy, but slick). The coolest feature though is the search field at the top of each column of data that you get when using dry_scaffold.

  8. satadru Says:

    In fairness, overlordishness is necessarily predicated on some sort of code drop soon. I’d love to help dog food, but alternatively, as time goes on, i’ll be forced to invest time in some other product…

    ;-)

Leave a Reply