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 find myself wanting to develop certain projects, but most of the time I lack motivation because I develop by myself.
What I usually do is look for similar existing projects, and ask the developers if they like to collaborate, but it's rather hard.
Is there a good place (a website maybe) to find people that are interested in the same project as me, and therefore would like to collaborate?
You code by yourself?
Release the code on one of the open-source foundries. (code.google.com. sf.net. bitbucket.org , github.com ,etc...)
Pick an easy license (x11/MIT is good, GPL2/3/AGPL3 if you like, among others.)
Write simple instructions on how to deploy, run, with a one-page tutorial.
Have a website where you write about the stuff you build, and the stuff you'd like to build.
Find people who need some help and help them. Don't over-extend yourself.
It takes time to build trust. Trust takes time.
Update
You wrote:
What I usually do is look for similar existing projects, and ask the developers if they like to collaborate, but it's rather hard.
If you see an open-source project out there, odds are the developers already like to collaborate. What they might not want to do is talk about grand schemes about how to turn the software into the next fifty billion-dollar behemoth. Generally, if you join the mailing list, introduce yourself ("Hi, I'm Joe, and I like to do X, and I like this software."), get and use the software, and provide feedback and constructive criticism, and demonstrate that you are following instructions or at least attempting to, and then, then, if you provide a patch (or a branch if github) it might be looked at and considered.
Do follow the project methodology. For example, if they use tests, submit tests with your patch, that sort of thing.
I tried myself to start an open source project and failed. I had published my idea in a forum and there were about 10 or 15 people who wanted to join the project. Actually there were very little activity ...
I think the main reason for the failure was that I hadn't developed anything before going public. It would have been really useful to have at least a prototype. Another thing is defining a (simple) development process.
If I would try it again, I would:
develop a prototype
document the code and the architecture in detail
write down tasks others could do
describe the development process
design a nice website and promote my work
publish the code at google code or something like that
Check out the offerings at github.com. If you can use git, I often find some cool projects on there, and you can always fork the repository to help out.
First, you should register your project on an Open Source Forge. There is a comparison list on Wikipedia : http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
On certain forges, there is a way to ask for help. I know that SourceForge does: https://sourceforge.net/people/
I recommend that you read Karl Fogel's excellent and complete book on the subject : Producing Open Source Software. It is freely available online or in print from Amazon.
If you already have some code somewhere online, you could put an ad for your project on Stack Overflow's Open Source Advertising.
Quote from the link:
It must be an advertisement soliciting the participation and
contribution of programmers writing actual source code. This is not
intended as a general purpose ad for consumer products which just
happen to be open source. It's for finding programmers who will help
contribute code or other programmery things (documentation, code
review, bug fixes, etc.).
Openhatch
is the best place I have found to look for open source projects
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
Step 1: Convince the president of my vertical to consider open sourcing a body of code
Step 2: ???
To give a bit more detail, I've already successfully convinced my boss and boss's boss to consider open sourcing a body of code that was written mainly as a demo platform for our company. We've already determined that the code is useful and understand the benefits to open sourcing the code.
Now the question is where to go from here? What are the next steps? The president said that he'd like to see a project management proposal which would contain details like:
Who would manage changes to the code?
What would the process look like to release new code?
How is the code review process defined before releasing code?
Who will participate?
What are the legal aspects that need to be considered first?
What I think I need is a "Open Sourcing Code for Dummies" guide or if there are some simple guidelines, how-to's, or templates for putting together a proposal available. I'd like to hit a home run on my first at bat and plop a solid proposal in his inbox. Any advice, resources, or ideas on how to structure such a proposal would be helpful.
I would consider the following:
Think clearly about the goals of open-sourcing your software and check all your decisions in this light.
Double check, if all licences of used libraries are compatible with the chosen license and you have the permission to use anything in the codebase. This also includes images or other non-code. If the source is world-visible, copyright-infringements are easy to spot, and your competitors might use the chance to make you trouble.
Choose an appropriate license. Most important decision might be copyleft (GPL, AGPL) or not (Apache, BSD, MIT).
Check your code again and remove anything, that you don't want to see in the public (silly comments or so).
Write a documentation to build the software from the source. If you have a good buildfile that could be as easy as 'make', but most likely you have to document about dependencies like installed libraries and so on.
Provide some way to contact your company about the software. maybe an e-mail-address and a someone, who answers to this e-mail.
If you want to attract external coders, document some important parts of the sourcecode. Provide some basic documentation about the structure, that external developers can figure out, which source-file they should edit, to change behaviour X of the software.
If you want to work with external programmers, you will need an world-readable Version-control. If you get patches, that are outdated against your actual codebase, it isn't helpful. If you have persons, who often send patches, give them commit-rights. Also an open bug-tracker is useful. If you don't want to host the two tools yourself at your company, use an Open-Source Hosting site.
If you choose a copyleft-license, let all external committers sign a contract, that give you permission to use their additions. Otherwise you couldn't use the changes in other propietary products of your company.
That's it, what comes to my mind at the moment.
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 8 years ago.
Improve this question
I have recently started working on some open source project which I found relevant to my interests.
During this initiation period I came across some terminologies/stuff that I am not acquainted with, like configure, tool chain, binutils, etc. which I agree depends upon the type of project you are working on.
Now my question is, are there some bare requirements a developer should know before starting to work on the project?
Any help/reference will be greatly appreciated.
EDIT:
I have seen the GNU configure and build system in most of the projects I have seen.
If someone bothers about it "The GNU configure and build system" is a good place to start.
If it's a pre-existing one, you'll need to read their development docs (if any), learn how to use their version control system, and have the requisite tools for building the code and running it.
If you have all that, and the knowledge of the code/language, then you just need enthusiasm and some spare time :)
I wouldn't define them as bare requirements in the sense that it appears you are looking for. If you're a programmer you already have (hopefully!) the self-learning and problem solving characteristics that probably led you to be a programmer at first.
You'll never really know 'everything', and will likely learn something new everywhere you go. Heck, I got my current job never even hearing the words "Model-View-Controller", but picked up the concept in no time.
Your examples, toolchain and binutils, are not complex concepts and a simple wiki article should suffice.
I'd suggest downloading all the source code and making sure you can build it yourself as a first step.
Try and make sure you are familiar with the overall design and documentation before attempting to make any changes to ensure you don't inadvertently break anything on your first change!
The terminologies being used will probably depend on the technologies being used, for example an open source project written in C++ and running on Linux, will likely be very different to a C#/.NET application build to run on Windows.
It depends on how much involvement you will get into. If you just want to contribute with a feature, just get the tools to build the project, an editor to change the file and enough doc reading to find injection point for your feature. If you can find someone to help you getting started it will be fairly easy.
If you are to be committed to the project I recommend learning build tools, project history and aims. Also how the current authors try to solve the problems, their perspective on the project will help.
I would say being able to understand all of the architecture, tools and technology for whatever project you're working on is a must.
However, you then tried to make this a generic question that applied to any open source project. You kind of answered that for yourself didn't you?
which I agree depends upon the type of
project you are working on
I would think that depends entirely upon the project. Most well set up software projects will specify:
What language(s) they're written in
What developer environments (if any) they're set up for
What tools you need to build/compile/run the project
Test data with which to test the software
What are you working on? Are you sure they don't provide any of this information?
It depends on what you qualify as "work" on the project.
Most of the answers here suggest that you're coding (and your question hinted in that direction), but there are things that you can do to contribute to projects -- like testing and documentation -- that can be done without knowledge of how the program's written.
Now, for the coding aspect of it -- if it's a smaller project, I'd try to figure out what the other contributor's motivation and grand plans/goals for the project are. As with any team, coming in and trying to take things in a completely different direction than the others are planning, even if you have good intentions, can cause all sorts of problems.
(and then there's the technical advice that everyone else said ... source control, build system, project architecture, toolkits used, etc.)
It depends, as you say, on the project.
You'll have to know how to work in the language, you'll have to be familiar with the source code control system they use (usually subversion). You'll have to be able to build (usually Ant, often Maven).
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
I've always worked in small companies, mostly doing small websites, and they all sucked in project management.
That means I have no experience whatsoever (even though I learned a little bit studying on my own) about the best practices and tools when developing a project.
Currently I'm unemployed to finish college and I decided to take a small PHP project mostly to learn both the language and project management.
It's just an idea I had for a website, I don't need to get money from it and it is not big, so I'm not concerned with deadlines or business plan, or a main goal. The main goal is to learn the technical stuff.
The only thing I'm caring about is doing it right, you know, the best practices in PHP, server setup, security, the tools for the job.
I'm not asking for a complete rundown on any points, just things like
Remember to always sanitize user input
Use this tool to manage version
Remember to set this apache option
Here's a good link on how to organize your files
Things like these will be already of great help!
Thanks
Non language specific:
Devise an error handling strategy early. What will you do when error conditions occur, will you log errors, how? where? What information will you log? Will you throw exceptions, return error codes?
Assume that your website is succesful, people start using it, then it breaks how quickly can you figure out what went wrong? Consider your whole error strategy from that perspective, not just from what happens while you developing and you're in control.
Some things that helped me a lot (in no particular order)
Version control (SVN in my case)
issue-tracker/wiki (e.g. Trac)
if you are writing markup: some kind of tidy
... and a validator
if you are writing code: a lint tool for your specific language
TODO-list app (for small TODOs)
a cheap VPS host to test things (I also use mine to host SVN and Trac)
There's a good question already answered about bug tracking and version control for single developers.
As for PHP style, I usually like to follow the Zend Framework guidelines. For deployment advice, you might want to head over to ServerFault.
Here's some answers to the project management / best practices side of your question:
https://stackoverflow.com/questions/601759/what-professional-standards-do-you-maintain-in-a-side-pet-project
Start off by choosing a framework you're comfortable with. I would recommend Code Igniter, CakePHP or Zend Framework. It will help(force) you with a basic organization of your code and files. All these frameworks has dedicated forums with passionate developers.
From the project management angle I would recommend you to set goals and milestones. It will help you get things done even though you're learning. Set target of that you should accomplish for this month, this week and today. Small and easy targets like "create signup form" or "set homepage set". It feel so good checking those off. There is a lot of tools to use for this, like Backpack or Basecamp (free versions) or Things (mac application).
Be sure to use PHP5 and not copy ugly PHP4 code.
For project management software, check out DotProject (http://www.dotproject.net/).
About PMS (Project Management Software), you can take a look at
[http://www.axosoft.com][1].
This compagny edits OnTime, a very nice PMS.
Moreover, this software is TOTALLY free for a single user !
This software provides full support of SCRUM development method, for me one of the best !
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
The producing open-source software book is a gold mine of information on starting open-source projects. Yet I am hoping to learn more from the experience of stackoverflow users and was wondering what are the mistakes you made when starting a new open-source project (or difficulties you encountered when attempting to contribute to a new project), and how would you avoid these traps to become a successful project*?
**Successful loosely defined as a project that is used, and attracts active contributors.*
My two biggest mistakes are:
I expect the world to fall in love with my project as soon as I post it anywhere. If I don't get immediate feedback how great I am, I quickly lose interest.
When I get quick feedback, I often don't respond on a timely basis because I have so many projects.
"Eat Your Own Dog Food."
Be your first user. This is good:
to know what you're doing
to motivate yourself
to get early feedback
I think it's nearly impossible to write open source software you're not using yourself.
"Eat Your Own Dog Food" tries to break out of the vicious circle: Nobody uses the software because it is not useable; it is not useable because there is no user feedback. Try to develop something that is useful for you and see if it sticks and gains some traction.
Besides using the software yourself “Release Often, Release Early”. With release I do not mean publishing some source zip somewhere but a real end to end release.
Choosing the wrong license (for different values of 'wrong') is a common pitfall. Two examples:
1.) If you're using a license that does not allow for relicensing under different terms and you accept contributors code, you need to keep in mind that the code suddenly is not yours anymore. This is fine for some hobby project, but might limit your commercial options later. Of course, it also limits other's commercial options too.
An example for this is the GPL. Include contributed code under this license and you're bound to the GPL yourself and can't decide to dual-license later (unless you nail this down for every contributor). Even a simple change of the license to a similar OpenSource license is impossible: See the linux kernel - it's bound to GPL V2 and can't be updated to GPL V3.
2.) If you're using a permissive license (e. g. Apache, MIT, BSD) you need to keep in mind that not only you can go commercial and close the code later, but anybody else can do so too.
Don't get me wrong: I like the GPL, I'm happily contributing to GPL projects and am glad that these projects exist. I also like BSD, Apache, MIT (the permissive ones) and am contributing to projects that others exploit commercially, e.g. through "Enterprise Editions" of the software that I'm getting OpenSource. It's all fair game - you just have to be sure what options you want to have later. None is better, they're just different.
The first pitfall is to start a new project when there are already plenty of existing projects that are planning to do the same thing.
Currently I am starting a blog based on a talk that I have given on the FrOSCon here in germany.
First article: There shall be light – things to keep in mind when starting a project
Maybe this helps. I don't know how long it will take to write the following 19 blog posts.
I'll answer clinton here:
Not so obvious stuff for new users is:
For User focused software:
getting started guide (Get the software to run quickly)
screenshots! Users love screenshots and too few projects provide them
For developer centric software:
getting started guide ("get to code quickly" for example by explaining dependencies, structure, compile and start process)
code of conduct
I'll think a little bit more about it and add it here.
Positively super great documentation is a must.
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'm currently studying computer science and looking for a good way to practice and hone my programming skills. Contributing to an open source project seems like a natural way to do this to me. I currently know Java, Python, and some C, but wanted to open this up to any established language.
In particular, I'm looking for a project that's fairly active and has a lot of work for less experienced coders.
A better known project such as Firefox might have the advantage of being more recognizable on a resume, but perhaps one could have a larger impact on a smaller project. Any thoughts on this?
Thanks in advance =) -Matt
A popular one to start on if you know C is GNOME - www.gnome.org
Another great thing to do is look for projects that need help by checking out the Help Wanted listings at Sourceforge:
http://sourceforge.net/people/
The Python website also has a Volunteer Opportunities page:
http://wiki.python.org/moin/VolunteerOpportunities
A good way to contribute also is to look at the websites and mailing lists of open source software you use on a regular basis and ask if they need help, or just browse through their bug trackers to see what you can help with. This would probably be more interesting for you as you'll probably be able to make more meaningful contributions quicker with an existing knowledge of the software.
Good luck!
First, it has to be something that you are interested in and will enjoy working on. Otherwise it may become a chore or you may not contribute as much as you might otherwise.
Second, I'd make sure the project is active and has people working on it who you can learn from (by seeing what they've done and any changes they might make to your code once you check it in and they review it).
Finally, if you have any idea what you might want to do when you look for employment as a developer, then try to find something related to that area of programming, a tool that is used by developers in that field for example, as that will help you learn about the problem domain, as well as how to program, which help improve your cv/resume.
Whichever sounds fun to do, that's a rule of thumb for side projects for me. I'd suggest you start your own by the way, this is always more exciting and can teach you "get the things done" skill.
I prefer contributing to an open-source project already actove. Depending on what you want you will find games, databases..anything you's think about surely needs your contribution.
My really first contribution was to a game that used opengl ...space stariods i think, it was more like an optimization, or bug fix, i dont really remember.
I've done a plugin for GAIM (now known as Pidgin).. but never get to publish it as it changed name and api structure. It should have display the currently played song in the status-bar..with lots of configure options. Never finished it though.
Another thing was a 'echo' plugin for XMMS, but i found some bugs, it crashed easily and random (during development phase) ..and it was no longer maintained in the moment i've started developing, so left it in the dark also:) This one i liked a lot.. lots of cool and weird sound effects.
They were all cool as they all used different structures, and already established rules for coding, and commenting. Lots of thing to learn like this instead of starting my own project which wouldn't change my programming skills in any way:)
jHeidi is a program I like to use, but which is a bit buggy and could do with some development. It's written in Java.
There's a clear roadmap: It's following the more advanced development of its sister project HeidiSQL.