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.
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
I am building a 'software as a service' website that will be charging users a small monthly fee. I am considering changing the Github repository over from Private to Public. Essentially open sourcing it. Is this suicide? I would like the community to be able to benefit from the code. It is unlikely that I will accept any push request so I'm not going to gain anything in that regard. It is community based, so I think most of the value would be lost by someone self hosting it. It is for a very niche audience so I doubt someone else will start a competing hosting. I would really like the code to be in the open, but not at the expense of my idea of course. How does everyone else feel about this? What is common practice?
Conclusion, I'm keeping it closed for the time being. I may look to open source sometime after launch however.
Since you are not going to accept pushes you might as well hold on get your code stable and then publish it for others to learn and benefit from. You are still building the service, so its not going to attract too many eyeballs either.
From a business point of you, you might want to have a reasonable community around your service before you opensource it. if you are still budding who knows if its taken up by a stronger competitor. If your idea is patented its a different story.
To be honest, and this is not likely going to be a popular answer, but to myself, I would keep it closed for a period of time.
The reasons for this are simple, establish your foothold in the marketplace, build your userbase, your brand, then it gives you a mechanism to market your product further by selectively or completely open sourcing components of your system.
I say do it for both personal benefit and potential strategic benefit ... afterall, alot of software IS a service
Most open-source projects stand to provide a return in the right circumstances. Don't forget, unless you have a patent or some massive advance that is so complex and unfathomable that nobody can re-implement it .. if they want to they will anyway, so you have little protection staying closed source anyway ... even more interesting is that the open-source equivalent may well overtake your proprietary one if it garners support.
People may send you great ideas you never thought of, or take your codebase in a direction you would not have predicted. Unless you have significant value in terms of IP or strategic position tied up in the source code ... releasing it will probably do more good than harm.
Also, by being first to the open-source arena with your code, you gain control over any resulting community driven development ... if somone reimplemented your functionality and went open source ... could you compete on any front?
I know it is a cliche, but probably for good reason, but read The Cathedral and the Bazaar and the essay Open Source as a Signalling Device - An Economic Analysis which is an interesting read. Michael E. Porter's texts on competition analysis are interesting when held up against the mixed value economics and competitive forces of open source and shows how disruptive open-sourcing a product can be to competitors ... and how it can add value to your market position. Also, whilst counterintuative, it can raise the barriers to a successful entry by competitors.
More food for thought on the advantages and disadvantages of open sourcing:
What the DoD thinks of open source
Alfred H. Essa "Innovation and strategic advantage: lessons from open source" (warning, journal link)
I like to fix flaws wherever I see them, and perhaps I am one of your users. I'd rather send a patch than send a potentially nagging-sounding email any day.
What benefit are you hoping to gain from making the code open source? If you don't want the input of other developers then there are very few advantages and a whole lot of potential disadvantages.
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.
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 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.
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.