Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As many of us do, I have lots of software ideas, a couple of really good ones, and not enough time to do everything. (I am a developer, but only one). I would like to open source some software and ideas in progress but also retain direction and vision of the project. Up until now I've only worked in non-free-as-in-beer software and it escapes me how open source could meet my need for control of it.
Let me be clear I don't intend to commercialize open-sourced projects for money. That much I know. I just want to have control of my vision which I start.
To control my own open source project I would need to manage it by providing guidance but that facet escapes me also, about how to manage something that's effectively free.
Am I barking up the wrong tree?
I've gone through this cycle myself, and can tell you you're way out in front of the horse with the cart. Not to sound harsh, but there's a frame of reference you should definitely gain.
First, "control my own open source project" -- is conflicting. Open Source involves giving something away, in this case to a community. So, thinking about control and ownership of something you've given away is a mental hurdle you need to cross.
Second, you need someone other than yourself willing to participate in your project. Without them, you won't have anyone to divert any direction and vision you might have.
Third, control in terms of project guidance is earned in any open source projects with any sort of following. It doesn't matter if you're the original developer with the initial idea; if the community is willing to follow your guidance, they will. If not, they'll simply not participate.
Enough soapbox. In terms of project management, divide the role into two functions:
1) Getting developers involved, taking on tasks, code reviews, guidance and direction, etc. Trust me, this is as much a sales job as it is credibility-based. Top-down, hierarchical, seniority-based I-was-here-first type of expectations is a sure-fire way to drive volunteers away from your project.
2) Repository logistics. In the end, you can control who are/are-not committers, their permissions, etc. If you do #1 well enough, this will take care of itself.
As a last bit of commentary, open source projects are not easy to get off the ground. There are more projects than people willing to put forth the amount of sustained effort necessary to give your project legs.
Good luck!
Well, Captain Bligh, it all depends on how you hand out commit permission, now, doesn't it? If you make the source open, but tightly control commits, then the vision is all yours. Assuming, of course, that you can find anyone else who cares enough to submit patches for your review and evaluation.
Linus Torvalds had a great speech on google talk about how he is using (among other topics) git to avoid having to include all code from the open source community! It is deffently worth checking out!
You probably can't have your cake and eat it too. If you open your source under a "real" open source license, then anyone who wants to would be able to start their own project. You could maintain control of the "real" project. Then it is a matter of waiting and seeing which version users like better, and which version attracts most of the community. You will always have control of "your" branch of the project. What you must accept is that someone else may become more successful with your original code than you are, and thus also have control.
In general, there are more ideas out there than there are developers waiting to work on them. So your real problem will likely be getting anyone to care about your project enough to contribute patches, let alone care enough to usurp control.
Even if you make the source available in a repository for anyone to grab, you still maintain control over the repository: you decide who has access, you decide which patches are committed (or at least, you decide who gets to decide which patches are committed).
However, this doesn't stop people forking your project and taking their forks in a different direction. There aren't any easy ways to prevent that: some people are ornery and will fork every project they touch, while other people might just have a different idea about how your code could be useful.
The best way to minimise forks is to be engaged with the community: be involved in discussions on the direction of the project, accept patches that add features that people want (while maintaining your own coding style and standards of course). If it's easier for people to work with the community and you than it would be to maintain their own fork, most people won't bother forking.
Of course, this means you've ceded some control to the community, because if you stubbornly refuse to give them what they want they're going to make a fork..
Sounds like the missing ingredient is some enthusiastic developers who love your ideas and are prepared to work for free.
I don't think they just pop out of the internet; you will need to go find them.
And once you find them, you need to keep them interested, which may well mean giving up some or all of that control...
Ask yourself what is your goal here–to deliver a software innovation to the world, or to have a pet project?
Well it just depends on what kind of project you are opensourcing.
Are you opensourcing one tightly defined core functionality in a small library, like a Ruby Gem, or a PHP PEAR Package, or are you looking to create the next Wordpress where millions of users have an opinion?
I would suggest starting small. Use something that you've written before, and can be used by others:
A jQuery plugin.
A Wordpress Plugin.
A PHP PEAR Package or a proposal to the Zend Framework.
A Ruby Gem that creates a behavior that can be used in Rails.
A module, or add on to some open source CMS.
Create a specific functionality that you want. Put it somewhere that other users can fork or branch your code, but don't let them merge back to the main branch or trunk of your code.
That way people can work with your code, but ultimately, you have control of what goes back into the official project.
Basically, you can't.
You can't prevent someone else fork your code and start a new project.
At most what you can do is to pick a license that says the source code can't be used to the same product ( I don't know which license is this, but it exists )
And secondly, what you can do is to have a very good control of existing base and a list a features you want to include.
If your project is forked, your new features will make less attractive the other.
Finally, your project will be forked if you don't work on it and leave it die. Otherwise nobody will come and fork your project when you're doing all the hard work right?
Here's a couple of interesting videos on the subject:
http://www.youtube.com/watch?v=-F-3E8pyjFo
http://www.youtube.com/watch?v=0SARbwvhupQ
If it's open source, at the end of the day you cannot control it - anyone will be free to fork it and go on their own sweet way. The way to prevent this happening is to be a "benevolent tyrant" and take on board other people's views on the project's direction. This assumes anyone else is interested in what you are doing, of course.
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.
Later this year I want to release a PHP framework that I've been working on as open source. I do use source control (SVN), but it's on an extremely limited basis. I'm self-taught, I develop by myself and don't have the experience of working with large teams. I have some ideas about what can help make a project successful, but I'm fuzzy on some of the details. Since it's not yet released, I want to do everything I can to set up the right infrastructure from the beginning. What do I need to know in order to setup and manage a successful project?
Some ideas that I have to make it successful (beyond marketing it):
Good documentation and tutorials
Automated unit tests and builds to
push update to the website
A clear roadmap
Bug Tracking integrated with the
source control
A style guide to keep the code
consistent
A forum for the community to get
support, share ideas, etc.
A good example application built with
the framework
A blog to keep the community informed
Maintaining backwards compatibility
wherever possible
Some of my questions:
How do I setup and automate a one
step submit-test-commit-generate API
docs-push update to website process? Edit: Would Ant or Maven be good candidates for this? If so, do you know of any resources for setting up a PHP project using them?
How do I handle (technically)
submissions from other users? How can
I ensure that those submissions must
be approved before being integrated?
What are some of the pitfalls that
can be avoided in terms of the
project community? I'd prefer to have
it be as friendly and helpful as
possible without a lot of drama.
I'd love to learn from your experience on any of these points. If you think I'm missing anything big, please share that as well. Any resources (preferably geared toward a beginner) that you could point me towards would also be greatly appreciated.
I'm just getting started in community projects, but I'll give you some advice on what I know.
How do I setup and automate a one step submit-test-commit-generate API docs-push update to website process?
I've never implemented it as one process. You could just have a checklist, and possibly even create some scripts to do certain tasks. I've never worked with any source control that automates the uploading and such to be done by a script. Most of the time, there is some web interaction to be involved.
You don't want to push API changes until it's an official release.
EDIT: Working Environment
For PHP, most of the time, I either edit directly on the server and test it there, using a beta.example.com, or similar, before pushing to example.com. You could also set up an web environment on your home PC (using XAMPP for Windows, or the standard LAMP installation on Linux). You would probably just use a mirror of your repository here, so you'd do svn commit, or whichever is appropriate for the VCS or DVCS you choose.
The fun part is testing this with different PHP versions. I've not done this myself, but you could probably use a .htaccess file to run a different PHP binary in order to test it out. I'm not really sure what the best option is for this is.
I've not done much with API, as I've never created a library, but just doing a quick search I found http://www.phpdoc.org/. It looks like a mature project, so that might be a starting point.
As far as creating releases go, I generally create a script that only includes the files that are part of the distribution (it will filter out any VCS files, and anything that you don't want in the distributed file). You could write a script around find on linux (which is what I do most of the time), or there may be other better options.
How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?
This is mostly handled by the bug tracker, and limited access in the Version Control System. Usually, you, and the people you allow, can commit to the VCS. Other users can submit patches, but then you might have someone review the patch, test the patch, and commit. You could split these tasks up as a team, or assign a patch to one person and have them do it all.
What are some of the pitfalls that can be avoided in terms of the project community? I'd prefer to have it be as friendly and helpful as possible without a lot of drama.
I would just make sure to keep it as positive as possible with the project members and community. There's going to be some disagreements, and it will drive a few people away, but as long as you have a stable product that meets the needs of most people, I think that's all that anyone can expect.
One minor suggestion that's worked well for me: start using first-person plural pronouns, rather than singular ones. That is, talk about "we" and "us" rather than "I" and "me." It encourages other people to participate when they feel like part of team, rather than when they feel like they're contributing your own self-aggrandizement.
The most important thing you have to do is to attract users. Without users, you won't get any contributions and developers helping you out. Because developers are users first, and then they decide to extend/fix something they use and might become contributors.
So to get users, you should consider
describe what your framework does in one or two sentences at the top of your project page
mention how your framework can be used and for what, what situations it is most useful for
add a lot of examples on how to use it
mention whether your framework is stable, beta or alpha. That's important because user need to know that before they start using it
also mention whether you want to keep improving it and keep working on it - most users don't want to use a framework that's abandoned (also keep in mind that a lot of users check your commits to see whether you really are working on it - if your last commit to the repository was months ago then you're not really working on it, so cheating isn't possible)
If you got all this, and people start submitting patches, you can use a patch tool to apply those to your source. Depending on your version control system, you can either use the GNU patch, a diff/patch tool that comes with your version control or maybe even a GUI tool that helps you with this. SVN doesn't have a patch tool (yet), but 'svn diff' will create a patchfile which you can then apply with the GNU patch tool, or in case you're using TortoiseSVN, right-drag the patchfile to your working copy and have TortoiseMerge apply it for you.
And on how to best deal with the community:
answer questions in time, don't wait more than two or three days to answer questions
try to be nice, even with upset and angry people. Only if they keep bothering tell them to (still in a nice way if possible) go elsewhere
always keep discussions about the project on a mailing list. You don't want to repeat the same discussions over and over again - if you have a mailing list, just point users to the archives before the discussion starts all over again
And you should watch the talk "How Open Source Projects Survive Poisonous People (And You Can Too)" - it's really good and tells you a lot on how to deal not just with 'poisonous people' but also how to deal with all people involved in your project.
I'd like to add that you should make it as easy as possible for your users to get the whole thing running and modify the code - these 'power users' can be 'converted' into developers or at least people who send smaller patches.
Don't try to do it all yourself - for open source projects there are several hosting providers that solve most of the problems. I recommend codeplex or google code.
Setting up build scripts will depend a certain amount on what platform you set up, but in general it's easy to add any tool you want into the script once you start using any sort of build script.
If you really need the one step process you describe, you need a build server. I use TeamCity, which I have set up to watch for any changes in svn and trigger build/test whenever something is checked in. The build server will generally be able to perform any steps that you put into the build script.
Read up on Git as an alternative to SVN
free public repository/bug tracker/wiki/fork-enabled community in Github (which hosts symfony and PHPUnit amongst others)
"How do I handle (technically) submissions from other users? How can I ensure that those submissions must be approved before being integrated?" - with Git, pull what you/your closest team finds most interesting to the master branch
Consistent API
be inspired of other public API:s
only change in major versions
guessable
Interesting for both users & developers
clear goal (your roadmap - excellent)
useful, contra everything else available
easy to use, but still not easy-enough-to-write/maintain-yourself
You could check out either Ant or Phing to build your project. Include CodeSniffer in the build and you'll save time checking for basic formatting errors/differences.
These are all technical tips, about the soft part... treat humans with respect, a lot of interest and be overly excited about their contributions and make them feel that they're not wasting their time. That would appeal to me.
Take a look at Karl Fogel's book on Producing Open Source Software. It probably has everything that you asked.
You should also plan for engaging the community. I'd recommend reading Jono Bacon's The Art of Community [http://www.artofcommunityonline.org/].
You have a great set of ideas to start. You might have to start by trimming them down! Ask yourself what's necessary for a first release.
For automating the builds and tests, the scripting can be done with ant, maven or phing for PHP projects.
You'll probably need a host so you can demo the product. For PHP that is pretty easy to find.
You need an open source hosting provider-- especially github (but also google code, source forge, etc). Github provides bug tracking, default licenses, blog and great mechanisms for accepting changes from the community. Built on git, it facilitates distributed projects quite well.
Although it's good to have a one-step build and install in place, automating integration of others changes probably isn't important (or desirable) off the bat.
Good luck!
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 7 years ago.
Improve this question
I know this is a general question, but I'd like to hear other people's opinion about our case:
I work in a small company. Our main development tool is PowerBuilder, which is a very limited IDE with a shrinking community. We've created some tools, which we use internally to solve a certain needs. They have neither been properly designed nor properly tested, and are not in production quality. OTOH, they do save us quite some time, and might help others as well. I'm sure other companies have the same kind of tools, and was wondering how common a practice is it to share them with others. As I see it -
The pros:
Good karma
More attention to our website
Perhaps getting fixes and improvements from others
The cons:
Without investing more development, the tools might make us look bad
Publishing of the code requires some effort
Some of the tools might be too specialized for our needs
The whole effort might go unnoticed given the shrinking community
Have you or your company ever contributed such tools, or used such tools developed by others? Is it worth the effort?
EDIT:
For those how wondered, the tools I had in mind include -
A tool that makes using SourceSafe easier, by listing objects that are checked out to the current user or others, backing up checked-out objects, and reconstructing PBGs.
A tool that recognizes PB controls at runtime, like Spy++ does (requires some infrastructure at the target app).
PBNI wrapper for SQLite (in-process access, no ODBC).
An SQL client, text measurement tool etc.
"Open source" originally meant you published a tool, and you made the source available. Because of some projects that expected, and in some cases through licenses demanded that changes to the source code be resubmitted for sharing, "open source" now quite often adds the concept of collaborative development to the mix. I did (or attempt to do) the latter; allow me to share.
There are magnitudes of difference between the effort associated with source available and collaborative development open source.
Leadership: You need to tell people the who, what, where, when, why and how of changes. And very possibly, you'll need to diplomatically poke and prod your volunteers. You may need to define the vision and prioritize goals of the project, and then enforce them when someone tries to take things another way. And, unless you only want people to come across your tool through serendipity, you'll have to advertise, running that very thin line (even thinner on the Internet) between attention-getting and gaudy. If the project is going to implement the concept of meritocracy, as many open source proponents say should happen, then someone will have to judge people's accomplishments and dole out the rights and responsibilities appropriately.
Work flow: I haven't done an exhaustive search by any stretch of the imagination, but I have yet to see a collaborative development platform that did all the things I needed. Part of the point of open source collaborative development is that the quantity involved in code review will cover any potential issues in quality of code submissions; I haven't seen a free tool integrated into a collaborative development platform that helped manage that cleanly yet (e.g. counting code reviews; auto-promoting after x reviews). We had to handle that, hacking manual methods into the existing tools. Probably at some point you'll have to define a version and create a build. Then there's the grunt tasks like documentation. (Ever try to release a new version of something free without release notes? The furor!! grin)
PB-specific issues: PowerBuilder is a commercial tool, and while there are cheap versions available, there are not free versions. The DRM added to PB11 has probably reduced or eliminated piracy that developers were probably doing to take copies of their office PB home, and while PB11 and later have a dual license policy that would allow developers to take home a copy legally (with permission and cooperation of the original license owners to create a second license), I don't see a lot doing it. (No scientific study, that's just what I see.) That cuts down a lot of potential collaboration, even from enthusiasts. Issues of compatibility of code between versions of PowerBuilder, plus the fact that very few people will own every version, will limit again your list of potential contributors.
Don't get me wrong. I'd love to see more collaborative development open source in the PowerBuilder community. I'd love to know how to work out the issues myself, and I have an effort in the works to see if I can make a new model work. (My first effort to follow the popular model failed miserably, IMHO.)
Is there a reason to feel badly about firing a ZIP file up to the web and forgetting it? I don't know. Is there any more pride or embarrassment in a 4 year old ZIP file as opposed to a SourceForge project whose last contribution 3 1/2 years ago was a post "Where the heck is everyone?" There is a reason why Sybase CodeXchange devolved from a collaborative development platform to a source available platform: next to no one was using the collaborative development features. If you source available open source your code, you'll have plenty of company.
BTW, CodeXchange may be an answer to your concern about visibility to the PowerBuilder community, although you'll lose the web site traffic. The PowerBuilder Web Ring is another, significantly less effective, method to help your visibility that keeps traffic on your web site, but it demands a navigation bar on the target page on your site. CodeXchange may also be a way to get over your concerns about code quality and narrowness of purpose of what you have to share. grin
What should you do? Don't underestimate the effort with a collaborative development sharing, but don't let it stop you from a source available sharing.
Good luck,
Terry.
You can probably discount one of your cons: Anyone interested enough in this kind of tool to be evaluating your offering is unlikely to be writing Company X are teh suxors on your feedback form; rather if they find some deficiency in what you have put out there, you are likely to get helpful bug reports or even patches.
If you can get your company to buy off on contributing to the community then I would go for it. it is always worth the effort to give back a little bit and this would definitely be a good way to get some of your tools out to the public and improved upon by the community.
As far as the cons go, I wouldn't worry too much about the criticism, it can only help you guys improve the next product you deliver and people will respect you from learning from your mistakes, nobody is perfect.
Even if your effort goes unnoticed by your shrinking community, future employees and clients will see that you are contributing outside of the company and may help with your reputation with them.
I think the pros far outweigh the cons on this one.
In short: go for it. I doubt there's little to lose, but much to gain.
The pros:
**Good karma*
never a bad thing to have.
**More attention to our website*
possibly a con if your code is really bad :)
**Perhaps getting fixes and improvements from others*
this is possibly the best thing you get from open-sourcing your code. Its all about sharing and helping each other, you get to use other's code, they get to use yours and everyone's gained from the trade.
The cons:
**Without investing more development, the tools might make us look bad*
I'd search through to remove dodgy/rude/stupid comments, tidy up the formatting etc.
**Publishing of the code requires some effort*
requires barely any effort - set up an account in Sourceforge, create a SVN repo there and import your code. Then create a binary package (a zip file will do) and release it using the website. Might take you an hour, if you stop to read all the documentation.
**Some of the tools might be too specialized for our needs*
You could set the whole lot up as a group - eg PowerBuilder Tools, then people who see the really specialised tools won't have wasted their time getting them, they'll still have the 'more readily useful' tools.
**The whole effort might go unnoticed given the shrinking community*
Possibly, but then there's really no reason not to release the code. If you don't it may get completely lost to everyone when/if you change development tools.
Publishing your source is a great way to get feedback. If you look bad because of it, that's ok. Just be willing to fix the problem. If you want help with your improvements I can't think of a better way than asking for help.
By the way, plenty of open source projects can be credited with the growth of communities that were previously shrinking.
I think you've done a good job of identifying the pros and cons. And it's probably true that the pros will outweigh the cons. If no one likes the utilities and does nothing to or with them, then you've lost nothing really; bad code shouldn't scare experienced developers (most experienced developers, especially PB ones, have seen their share of legacy code). If even one person benefits, then you get the karma, eh?
If you proceed to submit your tools to the open source community, do as you have here, and admit up front that the tools are not polished. This may deter some from even looking at them, however, if they are at least functional and can be easily modified, then they still represent a head-start for any prospective beneficiaries. As a PB user myself, I would be curious to know more about free tools that can give us an edge in productivity.
Have you looked into Sybase CodeExchange? They have some open-source PB things there, including the PowerBuilder Foundation Class framework.
I just saw your response to my question - amazing that you have developed something similiar already. :-)
Regarding your question: the company I work for has a specific section on the web site where tools which we used internally and/or simple solutions (or code snippets) which customers frequently ask for are published. The license of these offerings is very liberal as well, I think it qualifies as open source.
In your particular case, I'm fairly interested in the Spy++-like application you talked about since I was looking for (and/or trying to develop) something like that myself.
I'm aiming for something which doesn't require any infrastructure in the target application, but so far I'd be happy to play with anything which works, even if it requires modifications to the applications. I'm just not familiar enough with the PowerBuilder API yet to make a judgement on whether this is possible without modifiying the target application.
As I mentioned, I already developed similiar Spy-like applications for ordinary Windows applications as well as managed code applications (which require interaction with the VM to query the state of the object tree), so my hope is that I'll be able to find a solution which does not require any target infrastructure.
Do you have the source code up somewhere already? It doesn't need to be compileable, I'd just be happy to look how you did it in principle so that I can (hopefully) derive something from it which solves my particular problem. In case you didn't upload the source code yet, maybe you can provide some email address which I can use to contact you privately? I tried looking for something on your profile, but so far - no luck. :-)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
It seems that the normal progression to join projects is to contribute for a while, earn the trust, then get accepted as a member of the community (i.e. having commit access).
Now, I already apparently know "the best way" of how to get involed, in a manner of speaking; this is not my question; what I was hoping to attain is: How did everyone else get involed? Surely not everyone has gone down the "find a project and submit patches" route - or have they? I dont happen to know anybody in the open source community, so I'm just itching to know...
Perhaps you already knew someone in a community and just fell into it? Maybe you were getting frustrated with some bug and started contributing regulary as a result? Maybe you did just spot a project on SourceForge...
Update:
It seems that the most common reason is simply scratching an itch, to quote singpolyma: "Looking for a project to contribute to is often not the right way." Instead, you should join the open source community by contributing to a project that you already know and use.
Important:
Please, please, please: Tell me about your specific experience, no general answers please. Also, answer only if you are either a project member or a patch contributor. Please do not give advice on how to join a community, this isn't the kind of answer I'm looking for. If you would like to give advice on joing a community, please answer in this other thread.
Great Answers:
Mark Harrison talks about Tcl, cx_Oracle, kap and orapig
singpolyma talks about DiSo and Greasemonkey
Pax talks about contributing to GnuCash because of his wife
Related:
How to get involved in an open source project
How Open Source Projects Survive Poisonous People (And You Can Too)
My personal anecdotes:
I got involved with the Tcl community when it was first starting out in 1991 or so. The mailing list and later the usenet newsgroup were pretty important to connect with people. I specialized in user evangelism and teaching, and eventually ended up writing two books about the subject. One of them is still in print after ten years:
http://www.amazon.com/dp/0201634740
Now I use a lot of Python, and really like the cx_Oracle package. Again I was active in the mailing list, and contributed a few patches.
I've made a couple of software packages available that I had written for work. By making them open source, I was able to get some nice contributions back, and since they were not the "secret sauce" of my employers at the time, they didn't mind sharing the code. The two most popular packages were
http://sourceforge.net/projects/kap/ The Kinetic Application Processor -- this was built when I was working on the China Internet backbone.
http://code.google.com/p/orapig/ - OraPIG, the Oracle Python Interface Generator -- it generated Python code to call APIs defined in the database, and includes an XML-RPC database interface.
Advice:
Instead of looking for projects to join, try contributing to projects you already use.
It's often difficult to jump into the "core" development, because (a) on a big project, that might be a pretty big chunk of code to understand, and (b) there are probably a core group of people already working on it.
So, suppose you like a certain piece of software and want to start contributing, you can start working around the edges. Here's a couple of concrete tasks that will help you to become integrated with the group.
write some test cases for bugs to add to the regression test suite.
browse through the bug database and find a bug to work on. This might be the best way to get into the core development.
look at the feature request database and see if there's a small task you can work on.
look for "user doc" requests... a lot of them involve writing example code which you can provide.
Good luck!
The way people normally get involved is:
you use the FOSS product in your day to day work
you notice a problem or a missing feature
you mail the maintainer to ask if this bug/missing feature is real
the maintainer says yes, this is a bug/missing feature
you decide to try to fix/add the bug/feature
you code like mad
you submit a patch to the maintainer
the maintainer laughs in or face or says "thanks very much!
If you repeat the last few steps a few times, the maintainer will probably give you commit access to the project's RCS repository, and then you can really become dangerous. But the bottom line is that it is up to you to do something i.e. write some code - merely being "interested" in a project is not enough.
I joined DiSo and Greasemonkey.
The best way I've found to get involved is to get in early in the life of the project, or just be very interested. With DiSo or the various github projects I'm on, it was the former, with my Greasemonkey contributions, the latter.
Looking for a project to contribute to is often not the right way. Use stuff and find out what you want to build/fix, then do that.
I did a little bit of patch work on GnuCash since my wife restarted work part-time recently after our kids were a little more grown up.
I would've rather had my eyes ripped out with a hot poker than re-install Windows but GnuCash was missing something that [a certain other accounting package] had so I told her I'd get it added.
As it turns out, they took my patch and made it a lot better before putting it in (to the point where maybe 1% of the final patch was my stuff) but at least we can now use GnuCash instead of that proprietary stuff. They were also incredibly responsive - from patch submission to patch availability was only a week or so and it was in the product three weeks later.
I also once investigated getting a patch into the process accounting in the Linux kernel but the effort required far outweighed my needs :-)
I don't contribute on a regular basis, more as-needed (find your itch and scratch it). There are some who make a hobby of it but I'd rather be spending my spare time with the kids and, unfortunately, my employer won't pay me to contribute elsewhere.
That last bit particularly galled me since:
the Linux patch would have greatly assisted our product (and a lot of others).
it was change in behavior of another of our products that degraded the usefulness of our product.
the solution was fairly simple, conceptually (the effort required was testing since a problem would have been high-impact [task switching] and very pervasive [everyone using Linux]).
it would have been quicker to code up the patch than the workaround we eventually implemented.
the workaround is a kludge (p'tooee).
now, nobody in the world has the benefit of our patch (including us).
What I did was pretty simple; I opened one.
I have been joined by one permanent developer, and other two who donate code behind the scenes. The project is in very early stages, so not many users have downloaded it.
What really helps an open source project is having a plugin architecture.
It's much easier to contribute a simple plugin for eg. a file format than to try to add something to the Linux kernel. This makes it a lot quicker and easier to build a community.
TODO: Please supply an anecdote.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I was always wondering about this seemingly utopic world of open source.
Assuming the vast majority of users here are professional software engineers which need some sort of income source, I assume most of us hold stable, money-making jobs.
So who are the key players in the open source community? Who are the people which devote their precious time to these projects? What is their benefit? Are the majority just people who see a bug, fix it, submit, and forget about the project? Or are they people constantly involved in the process of building the product?
How do you find yourself contributing to open source projects?
I earn my living doing professional projects that are based on either open source frameworks or commercial products, and quite often a combination of both.
A lot of the commercial products I have used over the years end up being really very expensive in the end. Let's say you buy a Single-Sign-On solution for web apps. By the time you're finished with what you have to do, I and a lot of others have experienced that you end up re-implementing 2/3ds of it, and sometimes there's almost nothing left of the commercial product you thought you were going to use.
So the problem with buying stuff is that it never fits, and quite often the purchase decision is based upon function-matrices that compare features whilst not actually considering the suitability of those features in your own environment.
What I'm trying to get at is that mature organizations understand that there's no such thing as a free lunch, even after you paid for the product license. The fact that you spent $1M for a content management system does not mean you're not going to spend another $2M doing 50% planned and 50% unplanned activities related to that.
So we can, will and do write patches for all OSS projects we're involved with. Sometimes we rework subsystems, and most of the time we submit it back. Sometimes we decide we only want 50% of the framework and we just fork of the rest for ourself. But we still want to stay with the framework for that 50% which we use. Try doing that with a commercial product ;) In general we try to stay on the "developers " mailing list, but we seldom bother to get commit rights for the projects.
My greatest contribution to open source projects has not been by contributing code to them, but by just actually using them.
Philosophically speaking, that is probably just as nearly as important to the health and utility of the project, actual users who submit feedback and leave suggestions and comments in daily conversation or in sites like this.
Are the majority just people who see a bug, fix it, submit, and
forget about the project? Or are they people constantly involved
in the process of building the product?
I definitely fall in the first category (focusing on a long term project is just not my thing) but there are plenty of people that are part of the second one. Without them we wouldn't have much of a viable Free Software ecosystem. A significant portion of these people are paid to write and maintain Open Source software but there are still a lot of hobbyists who do it just for fun. In fact, most people I know who are paid to work on Open Source software would still contribute if they had to do it for free (I certainly would). Contributions would just be less frequent.
How do you find yourself contributing to open source projects?
When I was a student I played with internals of various free/open source softwares (including gdb, OpenSSH, arping, some IRC clients, Snort, various Perl modules, some Debian specific packages things,...) and fixed some bugs as well as implementing a few features while doing so. Nothing big in term of SLOC and some of these contributions were rejected but it was still fun and interesting.
I co-founded a Free Software Users Group which has been running for over 4 years now. At meetings I sometimes give technical presentations about free softwares. We also try to regularly attend external events were LUG/FSUG are invited.
I also often buy T-shirts, sweaters and fluffs from projects I like as a mean to give them some financial contribution.
I am now doing technical support at an Open Source company and as such I report bugs and write fixes routinely. And they actually pay me for that. Why choose between contributing to Open Source and having a real job when you can do both?
It's a lot about pride in something you do. Also gaining the confidence when code you do is accepted by peers.
After that initial phase, is a lot about being able to manage code builds and releases, suggesting new ideas and practicing your skills.
Some people in open source projects do them because they feel the freedom they do not get from work is liberating.
I personally try to contribute as much as i can, from documentation to bug fixes. That isn't to say i do much, but i like it when i can.
I have started my project because at that time I couldn't find any application that was what I had in mind. I have made it open source beacuse Sourceforge had an excellent infrastructure I was not willing to cope personally with.
I barely make enough with Google adsense to pay for the domain name and hosting, apart from that it was a lot of fun over the years. And a refreshing experience being in complete control of what you do, which is certainly not the case in my day job.
I earn all my living doing professional projects based on open source web framework (Aida/Web) which author and active contributor I am. The same goes more and more for others in our community as well. They are earning money and at the same time contributing back to the tool which actually enables them earning that money. The loop is therefore closed, to the benefit of all. I'm quite sure that such a model is the best for the open source and many other open source guys are following it as well.
All my OS projects started as real business needs that needed to be satisfied. Once the job is done, I can release the applet or whatever to the public via Google Code. I haven't had anyone submit a bug report so far, and I doubt I ever will. Most of the things I post are fairly small but, hopefully, useful. Personally I don't beleive people who use OS software submit bug reports at all: they just go and donwnload something that actually works.
I do both.
I am not a "major player", but if I can help a little in improving a project that interest me, I do what I can, from adding a bit to the documentation, pointing out some possible improvements, fixing a bug, providing a patch.
I helped a bit to improve a PHP framework, for example. Sometime I provide or improve French translations.
There is at least a project in which I was (still am, although devoting much less time now) quite involved, Scintilla and SciTE (I am near the top of the chronological list of contributors in the SciTE credits). Of course, my main interest is to have an editor fitting my needs and tastes. That's the spirit of open source, to get contributions of people with a strong interest in the project.
I helped, but in the same time, I learned a lot, so it is a good deal for everybody.
I've been working exclusively on Open Source now for three years, in addition before that I did FOSS as "hobby projects". We're using our own Ra-Ajax to get consultancy gigs. This first of all makes it possible for us to create OSS which is very rewarding and fun! Second of all it create better tools for ourselves in addition to that we since we know the tools in and out often can charge better prices then if we were working with some "random thing" which "someone else made"...
How do you find yourself contributing to open source projects?
I think that, like programming itself, it has a lot to do with your passion and interests. If you are working on a project, or are interested in a topic, and find yourself needing a tool or a module that does X, go search it out. Chances are that there is at least one other person who has released an open source project that does it already. Depending on what you find you can:
Use a product and help the owner make it better via bug reports/fixes and feedback.
Improve on the product and submit your changes back to the owner.
Make your own product and release it as open source for others to do the first two with.
Chances are good that when you are first starting out that you won't become and overnight open source rockstar. Like the internet itself there is so much out there that you probably won't be noticed right away. However, just going through the process will teach you enough to make it worth while.
That is where I am. I have not made a name for myself in the open source community. I have learned the names of a handful of key players through reading blogs and just using the code, but that is really missing the point of open source. I have found some really great tools and have improved my knowledge and coding significantly, which is what is important to me.
In my experience, many people I have talked to see open source in one or more of the following ways:
A hobby for super hackers.
Something that people do for charity.
A source of free code examples.
A human right.
A place to find temporary solutions.
I see it as a great opportunity to learn, add tools to your toolbox, find out more about your industry and others in it and have fun all at the same time.
Well, I've started off an OS project on my blog to address some of the perceived shortcomings/process speedups in the Visual Studio XAML process. It's not 100% open source at the moment because I'm the only active developer on the project, but I have had people contribute source to the project which has been a fantastic incentive for me to continue developing it.
On a slightly different note, I've written applications and articles that have been posted on Code Project, so people are free to download them and use them as they see fit. My theory - if I've put it into the public domain, then it's free for you to use as you see fit; I don't want any money for it - that's not why I wrote the article.
Contributing to open source projects is a great way to hone skills that may not be in your main development set, so this is a really good way to improve your CV.
Reported bugs. Written articles. Answered questions on forums/IRC. Even started up my own OSS Project (Which I've handed over to someone else since)
I would really like to contribute to OS projects, however with three kids and a full-time job I never find myself with enough time to do anything but consume OS. Hopefully that will change sometime soon, but I do believe there are at least more than a handful of developers that are in the same boat with me.
Honest answer: Not much.
I've written a lot on my own, but I don't really consider that contribution. The most I've given to other projects is a few bug reports.
Using it.
Promoting it.
Creating a tiny open source project (Natural CLI).
I pretty much active in an open source project named :
JStock - Free Stock Market Software
I can improve my $ncome (by using JStock to perform investment) and write code at the same time :)