Getting the open-source-workflow into the business
Upcoming SlideShare
Loading in...5
×
 

Getting the open-source-workflow into the business

on

  • 309 views

A talk given at the Software Passion Summit 2012 in Gothenburg Sweden.

A talk given at the Software Passion Summit 2012 in Gothenburg Sweden.

Statistics

Views

Total Views
309
Views on SlideShare
308
Embed Views
1

Actions

Likes
0
Downloads
4
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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

Getting the open-source-workflow into the business Getting the open-source-workflow into the business Presentation Transcript

  • Getting the Open-Source-Workflow into the Business Carsten Nielsen 2012-03-20PRODUCTS • CONSULTING • APPLICATION MANAGEMENT • IT OPERATIONS • SUPPORT • TRAINING
  • This is D.
  • He lovesmaking music
  • He lovesgood food
  • He loveshis family
  • He lovesnature
  • He is human.
  • And he is a Developer.
  • As a Developer he is curious
  • As a Developer he ischallenging himself
  • As a Developer he is experimenting
  • As a Developer he is passionated
  • As a Developer he is passionatedThats why he got his job.
  • His job.
  • D growing intothe OS-world.
  • Creating a relation.
  • Requesting support. First contribution.
  • Giving support.Knowing the users.
  • Passing problems.
  • Checking and filteringSupporting the upper levels
  • Get stuff fixed.
  • First code-contact. First commit?
  • Discuss/request new features.
  • First level of creation. Adding newfunctionality.
  • Call to core.Discuss the concept.
  • Commit to core. Innovate.
  • btw:Dreyfus levels ofskill acquisition. (Thanks Staffan!)
  • The difference to business?
  • Remember the scrap-press?
  • HUGE STORAGEMULTITASKING FLOW
  • DR C. (Csikszentnihalyi):
  • Structure inbusiness nearly the same. But...
  • TheComfort Zone
  • (freely chosen)LOCATION
  • (freely chosen) TIME
  • (freely chosen)LEVEL
  • The Comfort Zone enabling thehighest productivity in relation tothe actual state of D.
  • This will make you happier:No multitasking → keep role & level Enrich your data → read & meet Find & define your comfort-zone Communicate!
  • This will make you sexy: Create transparencyDrop rules → create opportunities Support swap/change Communicate!
  • Carsten Nielsen carsten@redpill-linpro.com @phreaknerdPRODUCTS • CONSULTING • APPLICATION MANAGEMENT • IT OPERATIONS • SUPPORT • TRAINING