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
