community-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de.INVALID>
Subject Re: Apache Consultants/Jobs portal?
Date Sat, 22 Jul 2017 11:19:45 GMT
Excellent topic indeed!

A few thoughts and feedback from my personal experience.

A.) Many companies still only see the downsides of contributing to OSS. They often take OSS
as 'free as in beer' and use the libs.
And if something doesn't work then they add local workarounds. Because contributing is 'soo
much work'.
They do not understand that it's so much cheaper to properly fix the problems within the original
code than to implement local workarounds. Of course, if they don't know it you actively have
to tell them. Otherwise they won't learn.

B.) They also do often not understand that OSS is about sharing costs and creating networks.

Hack, being a JavaEE guy I have not much clue about the httpd myself. But if I ever had questions
I always found someone at the ASF who answered those questions. And if others have EE questions
then they often ping me too. That's a give and take. Having access to this brain-pool is almost
invaluable for your company. BUT they have to know that! And also need to know that this is
a huge sales argument for themselves!

C.) Don't limit yourself to your personal 'core' project. Whenever you have a project at your
company then watch out how you can improve it with ANY Apache projects. 
Of course you might need to investigate some time to dig into this other ASF project. But
it's worth it!
 * you make new friends
 * you learn something
 * it makes definitely more fun to play with high quality ASF code than with 99% of inhouse
frameworks.
 * It's also a huge gain for the company project as almost always the ASF projects have a
much higher quality than inhouse frameworks.
 * if you are already an ASF committer it's most times much easier to also become committer
on another ASF project. 

D.) Even in migration projects there is a lot room to have fun. It's like being a detective.
Of course it isn't fun to see dead bodies all along the way. But once you find the murderer
it's really rewarding. That's the same with software. Man, I could tell stories about stuff
I've seen in such projects. Like hand written JDBC drivers just to catch away Exceptions to
avoid that the application blows up (instead of just fixing the application), etc. Yes that's
ugly, but otoh it's also funny and really rewarding if you solved that bummer. Don't see it
as job. See it as a puzzle you're having fun to solve.

E.) Life is not a movie. Not every real life detective story ends with finding the murderer.
And not every software problem can be solved. Most times it's not even a technical problem.

It might be a political one. E.g the person/department accountable for the original design/software
might work against you. Name it, talk with them, make a clear point. IF they work against
a clean solution then escallate it to your management. If they don't change it then let it
be.
It also might be a resource problem. For that I like to refer you to Ward Cunninghams techincal
dept metapher.

F.) A wise man once told me: If you have a problem - solve it. If you can't solve it - live
with it. If you cannot live with it - leave it.
Better to leave such projects than loosing the fun in your job or to end up with a burnout
from fighting wind mills like Don Quxote.

G.) Don't be afraid to be grumpy and stand in for an obvious technical argument. If you have
good arguments and they won't listen to it then it will most likely not become an enjoyable
project anyway. And there are TONS of other projects which would be extremely happy to get
someone as good as you. 

I remember that I did a cleanup/review at a new customer. Totally broken setup, no tests,
shitty tools, shitty design, no data consistency, no transaction management, not even concurrency
save. With other words: screwed beyond repair. I did dig into it and curesed the whole day
onsite. My manager came to me and asked me to be silent or we loose the contract. I told him
how I see the situation and we worked up a 5 page letter with the most important things which
must be changed. Our management was fully behind me on this. We talked openly with the customer
and after they dug into our technical arguments they decided to change the whole project setup
based on our suggestions. Of course not every customer is so open to feedback. Many managers
are afraid that they might internally be made accountable for their old design decisions.
In that case -> leave them. They will drain anyway, even with your best support.


LieGrue,
strub




> Am 21.07.2017 um 10:25 schrieb Christofer Dutz <christofer.dutz@c-ware.de>:
> 
> For the last years I have been investing almost all my free time in Apache Projects and
the ASF itself. Unfortunately I haven’t ever been able to do a job using the projects I’m
spending all my time in. So I started thinking, why is this that way and how could this be
changed.
> I think in general you will probably get more public awareness by posting articles in
newspapers or blogs, but what if I would rather invest my time in doing instead of talking?


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@community.apache.org
For additional commands, e-mail: dev-help@community.apache.org


Mime
View raw message