Thanks for this email that's clarifying ideas behind the restructuring. I'm very excited about the organization idea but I have some points to expose:
2009/5/4 Adriano Monteiro Marques <[email protected]>: > 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. I think that everyone here want to know more information about that and how to help you to realize it. Probably it's better to create a separate thread or a private mailing list regarding the organization that's going to be created. > > 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) Acceptable. My idea is also to have an aggregated blog like planet.umitproject.org that collects blog posts of contributors. > 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: Regarding this will be better to create a democratic survey to have a clearer idea on how many agreed with that. If the idea is accepted by a sufficient number of person we have to choose the namespace to use (umit,umitproject,umitorg btw there's already another thread in the list to discuss it) > 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. This is not related to the common namespace but we have to define a documentation guideline that everyone should follow, like sphinx for user documentation and epydoc for API etc.. (It's only an example obviously. We could realize that trough a survey) > 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. These points are not related to a common namespace but by a coding guideline and by file headers respectively. > 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. I've a copy of higwidgets under my branch with little modifications and I'm using some of that classes in PM code. Concerning umit.core I've decided to not use its classes because are related to Nmap and umit configuration specifically and using those I would had certainly conflicts with other umit installations. So I would prefer to continue with PM.Core classes that offers a more flexible solution for my needs. > > 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 > > Sorry for my english I'll try to be as much clearer and concise as possible. Thanks for reading me! -- Best regards, Francesco Piccinno ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
