Since we see a lot of interest from developers who want to join the core development team at our
open source company db4objects
as a paid developer, I would like to share some thoughts about how we
and other open source companies hire. Most of the following is a
re-iteration of the thoughts Brian Aker, director of architecture for
MySQL AB, has
outlined in NewsForge.
We
are always looking for smart, accomplished developers, no matter where
in the world you are located – as long as you have a computer, a
development environment, and hi-speed Internet access.
Our
selection criteria are based on open source skills, on excellent Java
and/or .NET programming skills and we also like to see engagement for
our product.
As Aker puts it: "I'm not looking for someone who
sends a resume to my mailbox and hasn't looked at our product," he
says, "or who has a resume that has the all hottest current skills and
every popular certification listed on it."
What we look for
are accomplishments rather than credentials. Who contributes to related
open source projects, speaks at conferences, is a regular blogger on
db4o-related topics, or – best of all - who is a regular in our
Community Forums
gets our attention. Also, before we hire, we want to see that you have
made yourself familiar with db4o, its strengths and its weaknesses.
An
open source developer is someone who is smart about exchanging
information with the community. You need to be able to collect ideas,
to refine them for yourself and to share them with others. Your
communication skills need to be good, so this can work effectively.
Also, you should be able to work very independently along the path of
our roadmap. There is little hand-holding for those that work for us.
If
you do not yet have multiple years of development experience and if you
might be too junior to work on an ODBMS core, you could still be a very
valuable reinforcement for our team. You could start by writing
documentation or by building a well-commented sample application which
showcases a specific implementation architecture. If you share this
with the community you will certainly not only get good feedback to
learn and improve, but also our attention.
Aker notes, too, that
most open source project leaders tend to be good communicators, and
that writing documentation is a good way to show off your
communications skills. "And then you get the publishers coming around
wanting you to write books, too," he says, "and that's nice." The same
is true for db4objects with it's first book on its way within a year
after the open source launch – entirely driven by members of the
community and an external editor.
A great way to get affiliated
with us is to offer to do a project along a specification. If you see
that there is a feature lacking in our product, you can offer to write
it and accept payment only if it works out. That's the way many hires
started off at db4objects. This approach demonstrates your drive, your
judgment about what the product needs, your self-management skills,
your communication skills, and your result-orientation, all of which
are exactly the things we look for before making a longer commitment.
An
alternative path to employment with an open source company is through
working at another software company and by using db4o in a project
there. This will give you a lot of insight about using db4o in a
business environment and make you learn to appreciate its benefits
through own experience. While, as a general policy, we do not hire
directly from our commercial customers, we have seen several developers
ending up employed with us after one or two intermediary steps.
Resumes can be sent to
career@db4o.com for review.