Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am working in a small team on some projects in my spare time. We are having the problem that we seem to go in circles and are not able to get our products developed - however this is not a problem during my day job. The lack of face-to-face communication seems to have a real impact on productivity.
Any examples of software or methodologies in use by the open source development community would be appreciated.
If you read the history of most open source projects, they start with one person doing a lot of the initial work. If there's a team, it's small, and one person actually leads the team.
To pick one example. In the Python community, they refer to Guido van Rossum as the Benevolent Dictator for Life (BDFL). His word is (more-or-less) final. In many cases there are folks don't agree with him -- but for the sake of the Python community -- they seem to acquiesce to his judgment.
I think every open source project has a (singular) lead programmer who assures that decisions get made, and made in a consistent way.
Back in the olden days, Fred Brooks (The Mythical Man Month) described "chief programmer teams". Same concept. Someone is in charge of the technical content. Emphasis on the one. Nowadays we call the the "architect" or some such term.
No real methodology here, but I think 2 things are important:
Have well defined goals and
responsibilities.
Let each developer
have the last say in how their
allocated part should be done.
In open source projects the only real and strongest motivation is the fun to be had coding the product. Relating to #2 above, if people are told what to do, and they don't agree with it, the motivation starts lacking. Of course there will always be a bit of give-and-take like in any other type of relationship.
Also about the face time, Skype is great for having face to face meetings, which I recommend at least once a week or month (depending on the size and momentum of the project)
This is a difficult question to answer because "open source projects" is a very broad selection of projects. I think the defining characteristic is the project has a single unifying goal (perhaps, a set of related goals).
Are you on any open source mailing lists? I am subscribed to my favorite distro's mailing list and the developers e-mail each other many times a day. Also, there are other avenues of communication such as IRC / Instant Messenger.
I am not a RoR developer, but I would suggest skimming through Getting Real for some inspiration.
My guess is that your private projects are all run and coded by developers. Developers are known to... keep on developing. The big difference, in my experience is that a company has experienced managers that can define when things are DONE. I'd recommend putting someone on the task of defining goals and decide when things are done.
I've been on some projects where we had a lot more talkers than developers. My inclination is to ignore the talkers and listen to the coders. Even then there's usually one person who is in charge of accepting patches. There may be political issues they have to tread lightly around, but for all intents and purposes they have final say.
Linus has had some fairly famous issues with the same problem. Take note of this thread from 2006: Talk is cheap. Show me the code.
One more thing. Since you say in the comments that you do have code, just a lot of rewrites, I'd highly suggest you read Eric Raymond's The Cathedral and the Bazzaar. Eric's a bit of a nutter actually, but the essay is priceless for anyone wanting to run a Free Software project.
I'd have a think about your and your team mate's motivation and goals in this project. Are they to:
a) Create an awesome product
or
b) play around with software, and learn some new things
Both answers are equally valid, and i'm guessing it'd be a mix with a leaning towards one or the other.
If it's more of (a) then look at suggestions on methodology etc. Maybe even consider forming a company around your awesome idea. Because making such a thing takes work.. and well you probably get enough of that at work.
If it's mostly (b) then you're going to have a harder time making an awesome product, but an easier time in that you can forgive yourself for not getting there right away and suffering multiple re-writes. And you will all be learning new skills each time you look at it and work together which are very applicable to your long term careers.
Firstly i suggest you all be clear with each other on why you are there. Then look at paring back on what you are planning on doing, and release early and release often. If your project is made up of three components and one is complete, then release that as a separate component and start building a community of users. This will pay off as these users will possibly help you with your code, plus form a solid core of users for the full product and let you assess how you are going early rather than later.
Good luck.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.
The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.
Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"
Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.
Here are some observations in no particular order:
Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on GitHub in 5 minutes and don't look back. Put your energy in features.
Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)
GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.
But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.
You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.
If no one cares enough, it will die again. Try a different project where you do care enough.
"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.
I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.
Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code.
There's more to it:
Write documentation
Create graphical elements
Discuss features and roadmaps
promote the project
etc. etc.
Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)
This is kind of off-topic on SO, but I'll bite anyway.
Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
What are the key practical concepts that a fresh graduate should be educated with when he starts with his first programming job and how soon should you expect him/her to be productive and actually deliver the code you expect ?
source control and testing
Get them started with checking out code and writing unit tests first, learn what its about, and then go from there.
Yeah, that's a subjective question. We have done several summer and during-school internships as well as hired recent grads in CS.
If we start with a student who knows:
An OOP-ish language (Java, C#, VB.NET, C++)
How to fire up a compiler/debugger
How to work with our Source Code Control
Then given a defined problem domain with prerequisites (for example, for a recent intern, the problem domain was "adding autogenerated annotation metadata to TIFF files using self-describing barcodes"), the student needed to therefore know
How to generate and parse XMP
How to read/write metadata into TIFFs (we have tools for that)
How to read from a barcode scanner
Write unit tests
We saw progress in a week and saw demo code in a month. This was all within expectation. I mostly let him work on his own, but stepped in and course corrected some of his style and coding practice.
The important part of this is how goals were set and met. I made the important parts crystal clear (ie, requirements) and left the less important parts up to his design. After all, who wants to do paint by number all the time? For setting goals, I try in general to follow the SMART guidelines. A good goal is
Specific
Measurable
Avhievable
Realistic
Timely
It's very important that the project has a good feedback loop for communication. We were somewhat wanting in this regard.
Don't assume anything.
I made it through college without source control. Testing was stepping through the code with the debugger. No paperwork was needed for any assignment.
These 3 things are vital for production-grade code.
Just my thoughts and experiences:
Mentor. Assign a senior or lead programmer to mentor them. Not everyone is geared for this sort of assignment and a good mentor makes a difference. We have a mentor assigned to every new programmer - regardless of how long they have been coding - just to get the new employee familiar with our systems.
Start small. Depending on how your organization / team / etc is configured have the new grad start on some small maintenance projects, with a mentor reviewing their code and guiding them.
Get them training in the development environment your shop works in - expect that they will know a little about a few languages but that most of their development experience will be with school projects - not exactly solid production code. They will need a solid base to work from in the environment you use.
Code review and best practices - give them guidelines and make sure that they stick to them - if you are not using best practices internally, then start. Makes a huge difference when a large development group is involved. Review code frequently - this does not have to be a large group of developers in a meeting - one on one reviews, informal inspections, etc work wonders.
Develop an environment of cooperation - allow developers to mingle and talk and brainstorm - give them the opportunity to discuss ideas and thoughts that might not be related to the code at hand - they will rely on each other more then plants in the cube farm and production will higher quality. Allow them to read blogs and sites related to their craft - sights such as this one, coding horror, hacker news, etc. Support them going to local user groups and developer conferences.
Productive? That depends on the individual - some new graduates will never be productive coders but might be productive analysts or managers - some will be code machines out of the gate but will quickly churn out 1000 lines of maintenance nightmare code where 20 would suffice. I would say a fresh programmer out of school should be productive in 6 to 8 months - this is to say up to speed with you average programmers on staff, able to take a new project for your product, design and implement it, and able to handle any maintenance task required. It takes time to get the experience required to be productive - experience that can only come from actually developing in a production environment.
First: If you are a fresh graduate or a skilled developer - you always can gain new experience. So developers should be ready to always learn.
For the question: If your dev-team Practices Test-Driven-Development the first thing should be to show him how to write tests and how it can be useful.
Naturally the freshman should be able to use version-control, so if he relly has no skills at version-control a short introduction for this should be made.
Here are a few things I've found to be important for recent grads as well as new hires that have experience:
be proactive about including them in the corporate culture, don't assume they will fit in on their own
include them in meetings even if they are only there to listen
encourage them to interact in meetings when appropriate
be careful when dismissing their ideas as bad I've seen this discourage people from mentioning good ideas later down the road
Use of source control would be first on my list as very few schools need or rely on this. Really sit down and explain how to use the product you use and why it is necessary. Then for at least the first month, make sure to frequently check to make sure they are using it.
Next would be basic database skills. I've yet to see anyone come out of school really understanding how to query a database.
Third would be an introduction to your database and code base, explaining how things are done and organized and why.
Fourth, testing procedures and policies including how to do a code review, unit testing, QA etc. Tesing is not something that most students need to worry about either.
Fifth, assign a mentor if at all possible, someone the new person can go to for advice, to ask questions about company basics. You probably need someone to give them the basics of professional behavior as well. What is acceptable in terms of dress, attendance, etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I know how to find open source projects. I know how to find them. What I don't know how to do is ask for a list of things to do. Every dev mailing list I have been on has been full of actual developers. I never see any newer programmers present. Most open source projects do not seem new programmer friendly at all.
How would someone who isn't a very experienced programmer ask for things to do, while not seeming annoying or troublesome.
What are your opinions on newer programmers helping out?
**
Does anyone who has a project going have room for a beginner-ish.
I know intermediate C/C++/
The short answer - Start by becoming an active user of the project. It will make it easier.
The long answer -
The problem isn't that open source projects don't want help - most would be happy to have all of the help they can get. The problem is that most people who decide to help stick around just long enough to take some time away from the development team, then "flake out" and never show up again.
I have been very active in a couple of open source projects in the past, and we ran into this all of the time. It was very easy to get people to want to help, but very hard to get them to actually put the effort required into the project in order to be useful. I personally spent many, many hours trying to help out new prospective developers, and nearly always ended up just watching them disappear.
The team will be much more responsive if you can prove that you're serious - and it usually takes more than just showing up in a chat room, forum, or on a mailing list.
First off, I'd start by finding the right project. It's easy to find open source projects, but more difficult to find the one that's the right fit for you.
This is the difficult, or the easy part, depending on your point of view. I'd recommend starting with a project that you are familiar with - and hopefully one you've used. If you find one you're interested in, try using the software in its current state before you even think about trying to join the development team. If you are a user of the software, it's more likely that you'll be interested in contributing over time.
Using the project will do two things -
One, it will familiarize you with how they are thinking about the project. This will often make it easier to understand the design of the code, but most importantly, help you understand the goals of the current team.
Second, it's also often easier to get the ear of a dev. if you have specific questions to ask. I personally am always very responsive to a specific, directed, intelligent question. This helps build a relationship with the current development team.
Once you've become familiar with the team and the project itself, and have some idea of what's there, try to fix one or two of the bugs. This is an easy way to show that you can be productive and useful, and will be received fairly well.
At that point, the team will probably be much more receptive to helping you find good, longer term goals and tasks on which to focus. I've had a couple of people who approached our projects more along these lines, and we've all been very happy to help them try to figure out how to fit in and mesh with the team as whole.
That's the goal - you don't want to just be a contributor in the long run, you'll want to be part of the team. That's when you start feeling ownership over the project, and when it really gets fun.
It depends on what projects you're getting into, but often a look at bug trackers will help (few devs will turn down a patch to a reported bug). If you run Linux, Gnome Love is a collection of "easy to fix" bugs that should be perfect for a beginner getting his/her feet wet. My advice would be to pick a smaller / simpler project, as the codebase is easier to get oriented to.
I haven't rode the train of a particular project, but I'd imagine you have to prove yourself to the dev team.
For instance, take a while to familiarize yourself with the code base. Look at bug reports and see if you can track down some bugs.
Once you wrap your head around things, you can submit bug fixes, or implementation of some features. Maybe write some documents to help new comers wrap their head around the code base. Basically, do anything that demonstrates that you know what you're doing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Suppose you're working on an enterprise project in which you have to get management signoff in order for you to develop a new feature set. Usually your management has no problem signing off on some bright shiny new UI feature. Unfortunately they have a hard time appreciating some behind-the-scenes issues that are crucial to the application's well-being such as transactions, data integrity, workflow routing, configurability, security, etc. Since they're non-technical and these issues are not immediately visible, it's not obvious to them that this is crucial.
How have you convinced them that these infrastructural issues have to be dealt with and that it is important to their business process?
Every craft has its unsexy sides. Things that HAVE to be done, but nobody notices them directly. In a grocery store somebody has to organize how and when to fill the grocery shelves so they always look fresh. In a laundry you need somebody who thinks about how the processes should be optimized so that the customer gets his clothes in time.
The tricky part is: The customer won't notice when these subtle things have been done right UNTIL HE NOTICES THEY ARE MISSING! Like when the laundry is not ready on time but two days late, or the veggies in the super market have brown spots and look terrible.
Same goes for IT. You don't notice good transactions until your major customer knocks on your door and tells you that an important and expensive project has failed because the database entries of your product were mysteriously mixed up. You don't notice good security until customer credit card information shows up in Elbonia (and soon after word is in the national newspapers warning customers of your company).
The thing you really have to hammer in again and again and again is that software is NOT static. It has to be cared for even after its initial development phase is over. It is not just a product you buy once and forget about. Every car manufacturer knows that services is of prime importance to the products they build, simply because things WILL occur that have to be fixed and improved. It's the same with software.
So make a presentation, visualize, verbalize, translate your technical information into benefits. Business people don't care about your wish for code aesthetics in a refactoring project, but they WILL understand that your changes will help the product to become more reliable, gain a better reputation and reduce the amount of future service requests. Make them understand by showing them the benefits!
Same thing folks have been doing for thousands of years: draw pictures. Diagram the problems, use visual metaphors familiar to your audience, drag the problem into their territory.
Assuming they're not being intentionally obtuse...
A big +1 for analogies and metaphors. If possible, find one that will resonate with the personal interests of your audience (if it's 1-2 people). For general metaphors, I often find myself using commuter traffic or subways, for some reason.
e.g. We are currently migrating an app from an OODB to Postgres/Hibernate: the bulk of this work is done in Release '4'. Many domain experts have been asking why there are so few user-facing features in R4. I regularly tell them that we have been 'tearing up the city to put in a subway. It is very expensive and undeniably risky, but once it is done, the benefits in R5+ will be astounding, truly.' The true conversation is more involved, but I can return to this theme again and again, well after R4. Months from now, I hope to say "You asked for X and it is now very easy -- precisely because you let us put in that subway back in R4".
The surest way to get upper level management to buy off on development work is to present it in a quantifiable way. Ideally this quantifiable measure is in $$. You need to explain to them the consequences of skimping on data integrity, security, transactions, etc. and how that will affect the customer\user community and eventually the bottom line. You should be careful in these situations because sometimes management expects these non-functional requirements to "just work." If this is the case, you should either estimate high and work on these items alongside the visible UI work (ignorance is bliss) or you need to document these areas of need as you communicate with management so if things do go bad as you anticipate, it's not your job that is on the line.
Unfortunately, it usually takes a disaster or two before this stuff gets the attention it deserves.
It really depends what your management is like, but I've had luck with good old honest-to-goodness fearmongering. If you go through a couple of disaster scenarios, and point out someone's going to get blamed if they occur, that can be enough to make their arsecovering instincts kick in and finally pay attention :)
Car analogies.
Everybody knows that 'system' and it's sufficiently complex to depict the dire situation.
I'm battling with essentially the same kind of situation. Whether it is sign-off by management or acceptance by a user/sponsor, the problem remains one of different vocabularies, priorities and perspectives. I asked a simmilar question here.
I also got diverse answers, tantalizingly close to useful, but not quite definitive enough. Browsing and searching SO using relevant keywords led me to find usable insights in various answers spread out over many unrelated questions. To find and extract these gems led me to pose this question on site-mining.
It would have been useful to be able to flag the various answers and see them all in a single list, but alas, that functionality is not yet available in SO. I suggested it on uservoice.
Hope you find something you can use from the references I gave.
The right kind of countering question is the secret.
Is it okay to crash every 5 web pages?
Do we have to protect the credit card numbers?
Is is okay to have to pay contractors to deploy a patch every weekend?
Did you want it now or did you want it to work?
Robustness. When it comes down to it, you need to talk their language, which is how it affects their bottom line. If its a security or correctness issue, you need to tell them that customers aren't going to want incorrectly acting products, no matter how nice they look.
I like the idea of Technical Debt, because it enables technical issues to be translated (albeit loosely) into money issues -- and money is something most managers do understand.
Although the idea of technical debt was originally applied to architectural issues, it can be used more broadly for any type of situation where there is pressure to take a shortcut -- that is, go into technical debt -- rather than do it right the first time. (Doing it right is the equivalent to saving up to buy something -- it takes time -- rather than buying it on credit and going into debt.)
Just as debts can be good (e.g. home loans) and bad (e.g. credit cards), so technical debt can be good and bad. I won't try to characterise the differences completely, but good technical debt can be tracked accurately, so that you know how much in debt you are.
So, try to explain your important, non-UI problem in terms of technical debt, and the cost of not fixing it in terms of paying interest on that debt.
A descriptive picture really helps non-technical people understand what you are talking about. For example, below is an example from Sun describing how information is processed in one of their somewhat complex applications.
(source: sun.com)
Trying to explain this application in words would be impossible to a non-techy. Pointing at the diagram and say look, this part is our weak point, we need to improve it. That will make sense to them. If they feel like they have some understanding of what you are doing, they will be far more willing to support your request.