Architel Overlords Rule!
Satadru noted that he “welcomed the new Architel overlords” in a comment responding to disgruntled open source people. The overlords welcome you , Satadru! The real subject of this post is Defining the Terms.
I think the main problem is that Peter and Kate misunderstand what open source means (or what we think it means). I think Kate makes it clear that her definition of open source is different than ours when she says, “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”
Our understanding of open source is far different than that of Kate. We think the definition of open source is, “software whose source code is published and made available to the public, enabling anyone to copy, modify and redistribute the source code without paying royalties or fees.” Kate would disagree and suggest that “open source code evolves through community cooperation.” Community development is in fact how many projects evolve, but certainly not how they start.
Imagine trying to build software for ten different people with ten different specific needs. Now realize that the needs of 2 of the people would make the software useless for the other 8. How could you agree on what to write? Who is in charge? In the case of SimpleTicket we are building it for us. We made our project open so that others could a) use our code and contribute back bug fixes and needed features or b) use our code as a basis to build something that worked for them. Had we relied on Kate or Peter to build SimpleTicket it would not be very useful to our company.
We decided to release version one as an open source project and we plan to release version two as well. Perhaps version three will develop with the help of the a community? Or perhaps the community will simply extend the second version for the benefit of everyone… We shall see.
Openly Disgruntled?
Six months ago we released our internal trouble ticket system using the GPL open source license - we call it Simpleticket. Over 20,000 people have downloded the code (more than 100 per day) since release. Hundreds of people have emailed us thanking us for releasing the admittedly “flawed” code. We are about to release the second version of SimpleTicket addressing most of the problems and providing features we need. You see, we operate an IT support company that lives or dies based on our trouble ticket system. On the eve of the release of our new code the volume of disgruntled people is deafening. Check out some of these comments:
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. - by Frank
We were shocked to read this comment and responded here. Two people, Peter and Kate have spent a lot of time claiming we have not worked on the code with comments like:
you never actually WORKED WITH THE COMMUNITY. The non-architel developers were the only ones doing any work. - by Kate
And stuff like this:
Also the statement, “Alex and Rodrigo who added thousands of lines of code after the release� is patently false. Architel’s contributions to the branch called masukomi, which we all agreed would be the basis for hte next version, were very minimal. - by Peter
At the end of the day it really pisses us off. We wrote a ticketing system, released it using an open source license and let anyone download and use it. To say we did not get enough feedback when we built it, or that we did not do any work on it or that we did not contribute to their branch of the code is just crazy.
We wrote the damn software in the first place and spent the first 90 days resolving bugs so that we could keep our business running while using SimpleTicket. If you were to believe Peter or his friends you would think “they” wrote SimpleTicket and we were just using it.
We spent the last 90 days paying coders to rebuild the code, adding much needed features and bug fixes. When we release the new code I am sure Peter and Kate will be around to tell us what we are doing wrong (Peter has said, “However, I would love to see the new version when released.“), but man I wish they would go away. I wish folks we just thank us for the code and contribute code back if they want to.
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.
Community Contribution
Lots of you email me with ideas, suggestions and requests. Many of you are interested in joining our team. We are excited that you are even interested in the project. I was reading about the Mongrel and their open source community. Zed Shaw had some great points that I wanted to include here as a basis for the creation of our community:
No Code Fisting: Zed explains, “I worked with this guy once who walked into my office one day to tell me that he had started reorganizing the code base for the product. Problem was he started this completely useless reorganization two days before a big deployment, checked it into the CVS repository without telling anyone, didn’t get it working at all, and then had to go on vacation that same day. He was in my office to tell me to clean up his mess since his changes completely broke the build. He did all of this without telling anyone or asking first.
This is “code fisting�, where you shove large amounts of code at people where it isn’t wanted. When you do this all you’re doing is pissing off the people you work with and costing your employer money. In an open source project it can get you kicked out, ridiculed in public, and jeopardize your reputation.
I find that people who do this seem to not understand the #1 rule about working with others on a software project:
"Whenever you do something make sure it causes the least amount of suffering
for others."Change is important and the project needs it to improve, but if you go thrusting your nasty designs on other people in surprise Ninja moves then you’re not following the rule.
So how do you reduce the suffering that comes from big changes?”
Code Lube Required: Again, Zed explains, “Code lube is the answer to necessary code fisting. Code lube is a combination of communication, coordination, and gently applying your changes slowly over time until they’re in sync with the rest of the world. You have to baby step the other participants and if they aren’t receptive, then put your stuff into a patch or a branch and come back to it later.
This includes changes that aren’t related to code. Deployments need to be heavily coordinated. Moving servers, changing database schemas, installing new versions of tools, and changing important documentation all require talking with people.”
Zed’s post is a great read for anyone interested in an open source project. Thanks!
SimpleTicket Update
The new code was installed internally last week. We have been playing with it and making modifications. There are still some functional issues as well as visual issues. We are updating some of the wireframes to more closely reflect the needs of the design. Here is an example:
Note the additional button to replace fake buttons. Note the feed icon. Note the tagging function. The text on the lower right corner describes three of the drop down screens.  We are still working on a release very soon. Keep your fingers crossed.