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.d...@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-unsubscr...@community.apache.org For additional commands, e-mail: dev-h...@community.apache.org
