Hi Adriano. No objections. I understand all your (or, better say, our) goals. Now, I think there is no divergent thoughts about Zion, specifically. Zion's branch is already using the namespace proposed by you and Luis and I'm agree with that. Congratulations, great e-mail.
Att, João Medeiros. PS: Good stuff! Big things! On Mon, May 4, 2009 at 2:25 PM, Adriano Monteiro Marques <[email protected]> wrote: > Hello Folks, > > This morning, after reading all the e-mails concerning this matter, I just > realized that we're all (including myself) misunderstanding some basic > concepts. First, I would like to state that Umit != Umit Project, and I > would like to ask everyone to make that clear when writing anything that > related to these two different things. I sugest that everyone do that by > calling simpy Umit the scanner interface, and calling Umit Project the > organization that holds all other projects (Packet Manipulator, UMPA, Zion, > BT, BT Sniffer, Quick Scan, Umit Web, NSE Facilitator, etc.) > > After saying that, and keeping that in mind, I simply can't read all those > e-mails and distinguish when we were talking about Umit or Umit Project. I > believe that that caused most part of the confusion, and therefore I'll try > to clarify everything in this e-mail and after that I hope that we can > finally come to a better understanding on the goals of that restructuring. > Of course that by saying come to a better understanding doesn't mean to > accept the original proposal as it is, but it means that we'll be > understanding it better to discuss without any confusing feelings. > > > Umit Project goals: > Offer high quality software suite for network software development > and network administration. We tackle that by offering two main tools: > Packet Manipulator and Umit. Both can be used for the purposes I said. The > other softwares are part of these two, or are becoming part of it in a near > future. Of course we'll be creating other main tools to stand aside Umit and > Packet Manipulator in the future, but that's what we currently have and I'll > focus on discussing them. > > After we have these two main softwares stable, we'll try to release the Umit > Suite, which will be a package with Umit and Packet Manipulator inside. > User's will have the option to download both tools separately in the > beginning and them we'll start measuring if people really need them > separated or if they prefer to download them together (we'll do that by > measuring download rate). If it is the case that they need them separately, > we'll keep distributing the following packages: Umit Suite, Umit and Packet > Manipulator. Otherwise, we'll distribute only Umit Suite. > > Umit Project has being basically a GSoC based organization, in the sense > that we depend on GSoC to grow faster and have new projects developed. The > reason for that is clear: money. None of our contributors have a reasonable > financial condition to dedicate on Umit indefinitely without getting any > money from it. That's absolutely comprehensible as we all need that money to > survive and keep going. Umit Project's goal here is to create a meaning for > affording our contributors to work and get money from their work even > outside GSoC. In order to accomplish that, we'll need to: > 1 - Create the Umit Project Organization officialy, have a HQ, address, > registers, etc. > 2 - Create a business model to generate income and afford Umit Project > Organization growth. > > Currently, I'm working on those two steps and the expected outcome is to > have a sustainable organization able to hire our contributors (preferably > participants of [U|G]SoC) to work on improving, perfecting and creating new > high quality software for the main goal of our Organization, which is to > "Offer high quality software suite for network software development and > network administration". > > As far as I can see, this is the way to go for Umit to have it growing as > Apache did. I mention Apache because it is the most know example for *this* > situation (please, don't mix the Organization sense here with restructuring > package... try to forget that for a while now ;-). > > Then, as soon as we create the organization and state a business model, > we'll state titles and responsibilities for every contributor, propose new > projects, improvements, etc. and put our hands on it for more time than we > currently do and getting money for that. I already have a sketch of what > will be our business model, but I can't disclose it yet, because I need to > perfect it and check some possibilities. > > In order to achieve this goal, we foresee that Umit Project softwares and > contributors need to be gathered stronger than we currently are. If all our > softwares point to our Organization as Apache related project does, Umit > Project will be known better and more people will come after the > Organization's business model and the Organization will be able to afford us > all to work and improve Umit Project softwares. That's what I was talking > about when I mentioned Nash's Theory [4]. If we focus on working toward the > group, we'll all benefit from that with a consistent result, but if we keep > spliting things and thinking only on our own piece of software or what we > expect our own piece of software without pondering on the impact of our > decisions in the group, we'll all crash and burn. That's a nobel winner > concept. > > So, I invite each and everyone to join me in this new endeavor! I'm sure > that this will benefit us all with both financial and recognition odds. The > plan is also to provide quota on that Organization for some > worthy contributors. > > > Now, concerning the restructuring goals: > First thing to know is that this restructuring is all about Umit Project, > and I consider Umit Scanning Interface as an equal player aside all other > pieces of software. Umit == UMPA == Packet Manipulator == Quick Scan == Umit > Web == BT == ... They are all pieces of software held by the Umit Project > Organization. As there is no such official organization currently, they're > all held by Adriano Monteiro Marques (the copyright must be signed to a > liable entity) and they will be assigned to Umit Project Organization as > soon as it is created. So, as we're thinking for Umit Project Organization's > sake, we'll consider hereafter that Umit Project Organization owns all those > pieces of software. Umit Project owns those pieces for one reason: to > integrate those softwares to accomplish it's goal of "Offering high > quality software suite for network software development and > network administration". > > So, all our decisions here should be in first instance focused on "Offering > high quality software suite for network software development and network > administration" and right after focused on other colateral goals. I say > that, because UMPA exists for Packet Manipulator's sake, *but* it is also an > awesome alternative for packet manipulation library that can be used for > whatever purpose outside Umit Project world. That's the same for Zion > backend: it will be developed for Zion frontend's sake, *but* it will be > certainly a good library to be used outside Umit Project World. And we're > happy to tackle our main goal and offer colateral benefits! That's the goal > of Open Source, UNIX style development, layered development, and all those > fancy practices we try to apply in everything we do here. > > I said that, because whenever you have to decide upon something in your > projects you must first consider attending to Umit Project's goal, and then > after, attend to secondary needs. Anytime you find yourself implementing > something at UMPA, think of Umit Project's main goal, and then after that, > on secondary goals. If we can meet both, that's awesome. If we can't, than > we must opt for Umit Project goals. That's Nash Equilibrium applied in real > life. > > Does that minor the importance of UMPA, Zion or any other future library? Of > course it doesn't. Our main tools rely on those libraries, and as such is > true, we must focus on making the best for those libraries. If our corner > stones are not well stablished, how can our building stand? In that sense, I > would say that those underlying libraries preceeds the main tools in > importance, because they exists so those tools can exist. If they don't, > those tools won't either. > > After pondering on all that, and Umit Project's goals, I realised that if we > keep working on things separately, we'll never consolidate the Organization > and actually succeed by being recognized by accomplishing our goal of > "Offering high quality software suite for network software development and > network administration". An example is RadialNet. It is an awesome product, > and thanks to João efforts during GSoC 2007, we now have this important > piece of software implemented. But, due to the fact that it was integrated > into Zenmap and that it has an standalone version people simply doesn't know > where it came from. And that's bad for the purposes of this Organization. So > I wondered how could we fix this, and I realised that there are two things > to be done: > > 1 - Avoid keeping things separated. No project that we work on should be > offered by other website, domain, etc. That's good for you and that's good > for Umit Project. Why is that good for you? It is good because you have a > wider volume of downloads for your tool/library, a bigger community to test > and support it, and that will reflect to Umit Project brand, and as Umit > Project brand grows stronger that will reflect back to you. That's the way > it works for Apache Foundation (please, note once again that it is not > package namespace related that I'm mentioning this right now) > 2 - Setting a namespace. That namespace is simply a way to state where the > piece of software (tool or library) came from, and will certainly help us to > keep things sane, because: > 2.a - We can create a sane documentation structure, in which some enters our > documentation sub-domain, and under umit he can find every project, instead > of having to find if the code is inside umit, foo or bar. That's intuitive, > and keeps reference to the Umit Project Organization. > 2.b - Avoid conflicts. Someone, in another open source organization may be > working in a python module named pm, and that will conflict with us if it > happens that we provide our Packet Manipulator for a user that have that > other pm library installed. If we have umit.pm, that will be harder to > happen. I believe that this is the reason folks from Java world adopt this > namespace pattern, and also the reason why Apache does that. I collected > some links from some random projects under Apache umbrela and I could verify > that pattern [0], [1], [2], [3]. > 2.c - Standard. If we all follow this namespace, we'll all also have the > feeling that we have to follow the naming convention used by other projects > under umit. That's something that could work without stating a namespace, I > know that, but I noted that because it is a nice consequence of adopting > this namespace standard. > 2.d - Determine the origin of that software. If other organizations latter > decide to integrate our softwares into their, they will have to use our > namespace and that will keep the reference to us wherever that application > goes also. An example is the case for RadialNet, once again. If it was, > since the beginning, umit.radialnet, we would have helped to avoid part of > that confusion. > For those reasons, I decided that restructuring the packages are the best > way to go right now. I know that it isn't perfect the way it is right now > and that we need further discussions in order to improve it and define a > final model for that. Everyone is welcome to participate, but I want to > first ask you to think that this is a community and we must act > professionaly here. Think twice before writing something, and try to be > pleasant and polite in all you do and say. Criticizing isn't constructive > anywere in the world. If you want to construct something, start by putting > your brick, not destroying the other's brick. If you think that the whole > thing is wrong, it doesn't mean that you can come and hit it with a hammer. > We're all *mates*, and we can perfect our work and working environment by > sugesting, teaching and pleading. Flamewars are absolutely *unaceptable* > here, just as it would be inside a company. If we all keep acting like this > no one will bare fighting too long for Umit Project. And we want this > environment to be a bit different. We want it to be creative and > constructive, were people feel welcome and were they learn a lot. I'm sure > you also want to work in such a place. > Now that I explained my reasons, if you still is in doubt about the goals of > this transition, you're welcome to join in this discussion and help us make > Umit Project better today. But, please, if you're going to argue try to be > professional and not express personal feelings, don't treat your mate as he > was less smart than you, and try to keep the whole thing inside the > boundaries of what is best for Umit Project and the possible technical > limitations. I promise you all that if you do that you will benefit a lot in > both professional and personal senses. That's valid for me also, and I'll > try to keep aplying this the best I can to construct a better Umit Project. > > Concerning UMPA, Packet Manipulator and Zion: > From my point of view, there is no actual prejudice in this restructuring > for those libraries. If I see one, I would drop it, because it is certainly > against Umit Project's goals. It is good, because as I said before, those > libraries will became part of Umit Project's namespace, and that's good to > avoid conflicts and other bad stuffs (remember the zen of python?). > A few e-mails ago I said that it would be good also for the sake of UMPA or > Zion using umit.core stuffs. I regret, and apologize for that. It is indeed > better that we keep those separated for secondary goals, which is to benefit > outside world with high quality libraries. That is *ok* to not depend on > umit.core for those libraries. > Concernig Packet Manipulator, it is a different thing. It should use > umit.core and higwidgets whenever possible as this dependency is available > for every plataform that Packet Manipulator will support, it's small and can > be easily bundled in our installers and packages. > > Concerning the old hierarchy (umitCore, umitGUI, etc.): > I couldn't find any reference in my chat logs or email on that thing that > Guilherme stated on sugesting me in the past to change the structure to > something else. Although I'm not sure this conversation hapenned, it may > have hapenned indeed.That was the original structure for Umit, and at the > time he said he asked that to happen we were not as much as we are today, we > had other projects relying on that structure and I didn't feel confortable > on changing. If that conversation ever hapenned, that is the probable > motivation I can imagine. But this time, it was a different picture: > everyone was working hard outside GSoC, then you guys proposed that and you > did that all together. > As a project administrator, my main concerns are to focus on a scope that we > can afford to accomplish. If I just keep throwing things from my mind upon > you or accept everything that everyone proposes we will get stucked. That > was the time for changing, and you did. Now, what I asked was to continue > using that namespace for the other projects to come and to convert the > others which are not in that namespace yet. > So, summarizing: the fact of not accepting something doesn't mean I don't > like you, or that I think you're wrong. I love when someone comes with an > idea, and I feel bad also because I need to refute some of them. > > Conclusion: > Here is our reality... we're working on becoming a real organization. I > don't know when that will actually happen, but we're working hard on having > that as soon as possible. It will certainly happen after [U|G]SoC, because > we need to focus on our commitments, but while you'll be working on your SoC > project, I'll be working on having things rolling from the administration > side and have the business model well designed so we can start ASAP. > If after this e-mail you still have any concerns on the restructuring and > you are still against it, then you can argue. But please remember that this > is not a flamewar, and this is a working environment. Keep things in a > professional boundary, try to show creativity while resolving conflicts and > try to make our relationships and feelings about each other better rather > than worse while answering. I promise this will be a way better place to > work, and we'll all grow more professionaly and personaly by doing this. > If you simply disagree with the current structure but you believe that > restructuring is needed in the sense of creating a new namespace for the > purposes I exposed, then let's start a new thread for designing the new > structure. *Everyone* is welcome to participate! > > Kind Regards, > [0] > - http://struts.apache.org/2.1.6/struts2-core/apidocs/org/apache/struts2/package-summary.html > [1] > - http://logging.apache.org/log4j/companions/component/apidocs/index.html > [2] - http://excalibur.apache.org/apidocs/ > [3] - http://felix.apache.org/site/coding-standards.html > [4] - http://en.wikipedia.org/wiki/Nash_equilibrium#Notes > > -- > Adriano Monteiro Marques > > http://adriano-marques.blogspot.com > http://www.umitproject.org > http://www.pythonbenelux.org > > "Don't stay in bed, unless you can make money in bed." - George Burns > ------------------------------------------------------------------------------ > Register Now & Save for Velocity, the Web Performance & Operations > Conference from O'Reilly Media. Velocity features a full day of > expert-led, hands-on workshops and two days of sessions from industry > leaders in dedicated Performance & Operations tracks. Use code vel09scf > and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf > _______________________________________________ > Umit-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/umit-devel > > ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
