Getting the open-source-workflow into the business
•Als ODP, PDF herunterladen•
0 gefällt mir•413 views
A talk given at the Software Passion Summit 2012 in Gothenburg Sweden.
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Getting the open-source-workflow into the business
Ähnlich wie Getting the open-source-workflow into the business (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Getting the open-source-workflow into the business
- 1. Getting the Open-Source-Workflow into the Business Carsten Nielsen 2012-03-20 PRODUCTS • CONSULTING • APPLICATION MANAGEMENT • IT OPERATIONS • SUPPORT • TRAINING
- 3. This is D.
- 8. He is human.
- 9. And he is a Developer.
- 10. As a Developer he is curious
- 11. As a Developer he is challenging himself
- 12. As a Developer he is experimenting
- 13. As a Developer he is passionated
- 14. As a Developer he is passionated That's why he got his job.
- 15. His job.
- 30. D growing into the OS-world.
- 32. Requesting support. First contribution.
- 33. Giving support. Knowing the users.
- 35. Checking and filtering Supporting the upper levels
- 36. Get stuff fixed.
- 37. First code-contact. First commit?
- 39. First level of creation. Adding new functionality.
- 40. Call to core. Discuss the concept.
- 41. Commit to core. Innovate.
- 42. btw: Dreyfus' levels of skill acquisition. (Thanks Staffan!)
- 43. The difference to business?
- 46. HUGE STORAGE MULTITASKING FLOW
- 51. Structure in business nearly the same. But...
- 52. The Comfort Zone
- 54. (freely chosen) TIME
- 56. The Comfort Zone enabling the highest productivity in relation to the actual state of D.
- 59. This will make you happier: No multitasking → keep role & level Enrich your data → read & meet Find & define your comfort-zone Communicate!
- 60. This will make you sexy: Create transparency Drop rules → create opportunities Support swap/change Communicate!
- 61. Carsten Nielsen carsten@redpill-linpro.com @phreaknerd PRODUCTS • CONSULTING • APPLICATION MANAGEMENT • IT OPERATIONS • SUPPORT • TRAINING
Hinweis der Redaktion
- Carsten Nielsen: Php-developer/consultant at Redpill Linpro Curious about the motivation behind contributions to OSS-proects 1000's of devs are contributing 24/7 Why? Research, checking my own behaviour: - some points are based on scientific facts - some are my own experience/pov I got to one important thing: it's all about ->
- OK. Not again this mantra, we've heard enough... How many of you are contributing to OSS? How many are working agile? Is your company searching for talents? Well then this is for you. It's about the human side of business-value. The human aspect of devs. Speed, Continous delivery? You'll die if your not fast enough? Dinosaur? If you proceed squezing your devs you'll die. Definitely. Cause noone wants to work for you This talks intention is to improve the communication between devs and their companies by discribing one side of the relationship
- This is D. He is a guy like us.
- Making music Good food Family Nature Developer
- Making music Good food Family Nature Developer
- Making music Good food Family Nature Developer
- Making music Good food Family Nature Developer
- Making music Good food Family Nature Developer
- Making music Good food Family Nature Developer
- Curious Challenging himself Experimenting Passionated Thats why he got his job
- Curious Challenging himself Experimenting Passionated Thats why he got his job
- Curious Challenging himself Experimenting Passionated Thats why he got his job
- Curious Challenging himself Experimenting Passionated Thats why he got his job
- Curious Challenging himself Experimenting Passionated Thats why he got his job
- Midsized company 50 people Dev-team about 5 persons Multiple products/services The following scenario is a worsed-case-scenario: painting black and white to get the point...
- But he's under pressure. The first one is his -> Boss
- He needs: Estimations Facturate hours Inhouse consulting More business value
- He's hanging around at the phone doing support Discussing new features in meetings Yes that scary word: Meetings!
- Huh the team? Thats why I put them here: they have the chance to raise you but there is a risk: dependent things... And the same is ->
- Mini-Me: constant fear to hit the problem you're not able to solve. Over optimating code Even if your a professional craftsman (like sandro talked about) You're absolutely in the risk to press yourself
- Interesting side-effect: Tending to move in the direction with less press – physics!
- Lets see what happens in this case
- If you put something into this box:
- Money (maybe such strange things like provision-based-sallary)
- And you add control-structures to ensure that the employee/team works well by counting commits or quantity
- Even give them more time:
- D will produce more code
- He's producing a lot more code and fix more bugs/features But the outcome is: ->
- Scrap! It's a scrap-press Whatever you put into it: The result are cute little scrap-cubes You can stack them and they're working But they're increasing the dev/support time more and more...Lack of quality. Q&A won't hit this... D is feeling bad but he worked on OSS too so why is that feeling better?
- D in the wild. Searching for a solution... Tho there is a ->
- Demand: First level of relation but no personal involvement. He's just looking for a solution. He is starting to use this product. But now he's facing his first problems ->
- Support requests are the first level of contribution and involvement
- He's knowing the situation of the other users -> empathy He get honoured for his work – he's simply helping others! Starting to make the world a better place.
- When he hits the limit of his competence he is passing the problem This is: Getting the essence from the userbase – the results of the experiment.
- After contributing to research he's getting more and more insight. by walking along the process. Filter 1: passing the right things into the bugtracker or given it back to feedback-level
- Improvement stage. First contact with the code. Transparency by sharing and discuss. Filter 2: bad code out – good code in.
- Now he's actually starting coding... He learned from the open code as example by adapting their solutions He starting to 'read and understand' the code.
- By getting more insight into the system and knowing the user-perspective he's able to suggest and discuss new functionality Functionality: Extensions, plug-ins He gets more and more involved = relation = passion
- Risk: Passion = loosing the contact to the 'real user demand' Professionals shouldn't loose this contact to the base – stay on the ground and learn to live with critics.
- You're starting to be the bridge from the users to the creators
- Support from bottom to top. Creativity/skills from top to bottom. Communication-channels are optimized by level and use-case (git sourcecode comments)
- Support from bottom to top. Creativity/skills from top to bottom. Agile/Iterations are the same but in shorter cycles. But ->
- Creativity is required for the top-level Pressure is not enabling creativity. We all would be like MacGyver or like Scotty from the USS Enterprise: but we are not.
- Lets have a short look at the brain...
- -> Huge amount of storage-space We record nearly everything -> And the brain can multitask humans not Brain-multitasking is using all this data But the access is dependent on our situation -> Optimal: flow What is flow?
- What we do wrong: Multitasking the wrong way Stopped/Slowed down by conventions/rules Moving to fast. How does it really look like in OSS? ->
- We decide if we do sth. We decide what we do. We decide what when we do it. We decide where we do it. We decide how we do it. The results are permanent checked /discussed by the community/team. And this is the good «comfort zone»!
- We decide if we do sth. We decide what we do. We decide what when we do it. We decide where we do it. We decide how we do it. The results are permanent checked /discussed by the community/team. And this is the good «comfort zone»!
- We decide if we do sth. We decide what we do. We decide what when we do it. We decide where we do it. We decide how we do it. The results are permanent checked /discussed by the community/team. And this is the good «comfort zone»!
- We decide if we do sth. We decide what we do. We decide what when we do it. We decide where we do it. We decide how we do it. The results are permanent checked /discussed by the community/team. And this is the good «comfort zone»!
- We decide if we do sth. We decide what we do. We decide what when we do it. We decide where we do it. We decide how we do it. The results are permanent checked /discussed by the community/team. And this is the good «comfort zone»!
- You can swap/choose/change whenever you want. Thats freedom. That is enabling flow/creativity and innovation.
- How can we enable this in our business? You'd say: This isn't possible in customer-projects... It is. Partly.
- Transparency: required to navigate in a project and find the comfort zone. Required for quality/communication Oppertunities are not carrots! Swap wil improve your team-members