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 6 years ago.
Improve this question
I understand this question is on the edge of being acceptable for stackoverflow, but still, I feel it is worth asking.
I've started using bitbucket.org a couple of days ago, attracted by mercurial hosting, 1 free private repository, a wiki and an issue tracker. Just what I needed for my project.
I have to say, the features offered and the website's interface looks great, and I didn't have any problems with mercurial-related things so far. However, after these couple of days I am doubting if I should move somewhere else while it still easy (I haven't advertised the wiki page yet, etc...), because I am running constantly into minor and major issues:
Over these few days, I've noticed a lot of site slowdowns and a couple of timeouts
I find the wiki to be rather limited in features (apparently it is based on Creole Wiki, never heard of it before). It does not allow for, for example, right-aligning of images, borderless tables, etc. (well maybe it does, but the documentation doesn't tell)
I've noticed some bugs in the wiki (a TOC-generation macro issue was reported over a year ago, but still not fixed)
I've tried making my wiki public by changing the settings in the Admin panel, but it doesn't work.
some more wiki things [like inserting images is awkward, creating a new page isn't very obvious, internal linking has it's issues as well, .. ]
the sort order in the newsfeed was wrong when I pushed a multi-commited changset
It's very nice (and brave!) they have an publicly accessibly issue-tracker for bitbucket, but seeing a list of over 500 open issues (28 pages * 20 issues per page) doesn't give the impression they are taken care of as well as they could. At least some issues could have been moved to some 'will-not-consider' state. I am afraid my bug report about the private/public wiki page will still be in there within one year
The blog has a lot of post about 'downtimes'
Now, I don't want to be too hard on the people/company running bitbucket, since it isn't clear to me whether it is practically run by a single person (in which case it is truly amazing) or a well-run company (in which case it is not :-). Perhaps they have some growing pains... It is hard for me to tell.
So, what I am looking for here, is some experiences of other people with bitbucket, and advice if I should hold out, and wait until things improve (good chances for this?). Or not.
Jesper from Bitbucket here.
We're a pretty small team. In fact, most of the time, it's mainly me who does sysadmin/coding. This leaves very little time to develop new things, and sometimes, it doesn't even allow me to keep everything running smoothly (slowdowns/short outages always happen when I sleep.)
I realize this won't work in the long run, and something needs to be done. Therefore, I have decided to hire a bunch of people, mainly developers, but also a dedicated sysadmin and 1 or 2 UI guys (to make things prettier/more functional.) I'm currently wading through applications, and there are a lot of promising applicants in there.
Wrt/ stability, I've also provisioned 2 (much) larger instances from Amazon, where we do our hosting. We're throwing more money at this. I'm migrating a bunch of users/repositories to these larger instances today, and immediately following this, we will focus on making things faster as well.
Question was asked 2010, but I think this question needs a slightly more updated answer. I've been using Bitbucket for a few months now and as far as I can tell, it is an amazing git hosting system. You are provided with an issue tracker, wiki, unlimited public/private repositories, team collaboration, etc. Also, I have not yet encountered any downtime or slowness. On top of all of this, Bitbucket has an amazing UI, making navigating through source code and branches amazingly easy.
I would definitely recommend using this, and SourceTree.
I have not tested Bitbucket with really massive commits.
We have been using BitBucket HG for about six months, and I have little doubt but that we will move to a different VCS. It merges things badly, makes mistakes on complex commits, hurts our productivity. I don't know which parts are HG vs BitBucket, but I don't even have time to find out. Of course this is happening at the worst time, we have a do or die deliverable in two weeks.
I've been using BitBucket for a few years 1 year at my past employer and 2 years at my present employer.
It generally works fine without any problems. However, about once a month there will be some slowness. Over this particular week there were outages spanning multiple workdays where things were slow or we were unable to push our code changes for about an hour here or there.
So to summarize, most of the time it is reliable, but occasionally, about one day a month on average it is not reliable.
Related
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 9 years ago.
Improve this question
I'm working on an application and I needed an API wrapper for it. I noticed that most of the API calls I needed weren't implemented, so I went ahead with adding them in. There are a few bugs that need fixing which I'm planning to fix as well.
My problem is that development of the wrapper is almost non-existant at the moment. A bug submitted with a patch from October 2009 has been ignored so far.
I've emailed the main developer so I can commit my changes or even submit them somewhere, since on the homepage, it said that he's the person to contact with this sort of stuff. I've also asked about this on the discussion board, with no response.
My question is, how long should I wait for a response before forking this wrapper? It's one of only two open source wrappers for this API and listed on the API Doc's page. I hate to see that there's no improvements to it.
So, how long should I wait. What's normal for this kind of thing?
In case it matters: the licence is Simplified BSD
UPDATE:
The original developer finally responded; so I didn't end up forking. Apparently he was just very busy with work.
A good (relevant) article to read for anyone coming across this question: http://dashes.com/anil/2010/09/forking-is-a-feature.html
And thanks to everyone for your answers!
You can fork any time you want. Once I was in similar situation. As I had informed project admin that I'm going to fork, I obtained a response and it wasn't necessary :P
BTW I have written to sourceforge crew (project was hosted on sf) and that was their advice to fork.
Perhaps I am a little late but would like to answer on the level of definition.
The term Forking (branching away) refers to a split between groups and development in different directions. In this case a branching away can not clearly be seen so there was not actually a forking of a product. The action was clearly an alteration (extension) for a personal need. Should a product experience alterations and the result again be returned to the group it comes from is forking also not the proper definition. By definition open source encourages you to alter.
It depends if you plan to maintain your fork. If you do then the chances are it will become a better project than the original. Otherwise maybe wait a couple of weeks. Still, even if you released today there's nothing to stop the original project merging your changes so the community as a whole benefits either way.
There's no protocol, just call your fork something else and give the original prosjekt plenty of kudos for the original work.
Forks happen all the time, it's not necessarily a 'divorce' with the origial maintainers ... just happy coding.
Your additional calls might be usefull for someone else, but then again it might not.
Does the project has a publicly known mailing list/bug tracker, and if is - is it affordable to submit a patch there? Also, can't be a developer - become a maintainer at one of popular Linux distros, (submit a Gentoo bug/Launchpad entry).
If there's no sense in such actions - just fork.
Sounds like you've done the right thing though and tried to stay within the existing branch and now it is appropriate to fork.
If nothing else, forking is a more powerful action than most other things i.e. if you fork and still don't get the original developer's attention then you can be satisfied that you did the right thing. Of course once forked, there's no real reason why there can't be some convergence at a later stage.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Some time ago I observed a few people trying to start an open source project. About a week after the project started it more or less completely dissolved, partly due to issues with how the project itself was managed.
The ideas behind the project were however very well thought and a lot of people are still interested in seeing it realized. So far no one have made any serious attempt to recreate it but a few of us are thinking about doing so. Of course we don't want the project to end the same way it did last time.
Now to my question. How should one start a successful open source project, where successful is defined as "the project does not die unless no one is no longer interested in the software itself anymore?"
Nice question, though it's more worthy of a book than a simple article, IMHO. And I hope it comes as no surprise that most of the best advice is social, not technical.
Here are some observations in no particular order:
Don't make a big infrastructure investment up front Unless you're already an Apache committer (or somesuch), don't shop around for a sponsoring organization or host your own servers, etc. Get up on GitHub in 5 minutes and don't look back. Put your energy in features.
Lower the barrier for entry Don't make potential contributors jump through hoops or undergo a background check before you'll listen to their ideas. Open source projects are networked economies... you need the energy of others. Even misguided activity is better than no activity on your project. You can always steer the codebase in a better direction later.
Minimize custom code Don't write a custom logging tool or XML parsing API... there are open source implementations that are (1) good enough, (2) better maintained, and (3) better than yours will become anyway. The more energy you can focus on your core problem, the better.
Live on the edge People and organizations will only invest in improving your project if they will directly benefit. Eat your own dogfood. Create dependencies in your other projects (like with your employer) on your open source project, even if it isn't "perfect" yet. (Hint: software projects are never perfect, they're either works-in-progress or dead.)
GitHub is a good place because it makes it easy for someone with even just a little bit of interest to fork your project and apply his/her patches to share with others.
But it's really about the attitudes around your project more than where you host it or other simple considerations like that. Be benevolent, serious, and judicious, keep a community going even though it will be pretty small for a while, and so on. Accept patches that should be accepted, reject patches that should be rejected. Just be a good person, developer, and manager, and apply those skills to your project, and it should be fine.
You are saying it yourself. The most important thing is that it should have people who care enough about it to deal with the problems instead of abandoning.
If no one cares enough, it will die again. Try a different project where you do care enough.
"A lot of people interested in seeing it realized" means nothing if nobody will actually do the work, fight the fights and stay put.
I don't think it's set in stone, but for me the biggest point is that your project should fill a gap in the existing ecosystem. In other words, there has to a space for your project to live.
Other than that, I can say that the best way to stay motivated is to work together with people. You say that there are still a lot of people interesting in seeing it realized. So, why don't those people do something about it? Surely they can do something. I think a common misconception is that contributing to an open-source project means you have to be able to write code.
There's more to it:
Write documentation
Create graphical elements
Discuss features and roadmaps
promote the project
etc. etc.
Sure, not all of these points are applicable to every project, but trying to get people to commit to a project will eventually help you and/or your projectmembers to stay commited as well. You don't want to let down all the other folks on the project, do you? ;-)
This is kind of off-topic on SO, but I'll bite anyway.
Most FOSS projects are started by a SINGLE person. Other people come on board after this person has produced some code that does something vaguely useful. So if you want to start a project, do it yourself, set up a site on something like Google Code, and write some code. The last is the most important.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I know how to find open source projects. I know how to find them. What I don't know how to do is ask for a list of things to do. Every dev mailing list I have been on has been full of actual developers. I never see any newer programmers present. Most open source projects do not seem new programmer friendly at all.
How would someone who isn't a very experienced programmer ask for things to do, while not seeming annoying or troublesome.
What are your opinions on newer programmers helping out?
**
Does anyone who has a project going have room for a beginner-ish.
I know intermediate C/C++/
The short answer - Start by becoming an active user of the project. It will make it easier.
The long answer -
The problem isn't that open source projects don't want help - most would be happy to have all of the help they can get. The problem is that most people who decide to help stick around just long enough to take some time away from the development team, then "flake out" and never show up again.
I have been very active in a couple of open source projects in the past, and we ran into this all of the time. It was very easy to get people to want to help, but very hard to get them to actually put the effort required into the project in order to be useful. I personally spent many, many hours trying to help out new prospective developers, and nearly always ended up just watching them disappear.
The team will be much more responsive if you can prove that you're serious - and it usually takes more than just showing up in a chat room, forum, or on a mailing list.
First off, I'd start by finding the right project. It's easy to find open source projects, but more difficult to find the one that's the right fit for you.
This is the difficult, or the easy part, depending on your point of view. I'd recommend starting with a project that you are familiar with - and hopefully one you've used. If you find one you're interested in, try using the software in its current state before you even think about trying to join the development team. If you are a user of the software, it's more likely that you'll be interested in contributing over time.
Using the project will do two things -
One, it will familiarize you with how they are thinking about the project. This will often make it easier to understand the design of the code, but most importantly, help you understand the goals of the current team.
Second, it's also often easier to get the ear of a dev. if you have specific questions to ask. I personally am always very responsive to a specific, directed, intelligent question. This helps build a relationship with the current development team.
Once you've become familiar with the team and the project itself, and have some idea of what's there, try to fix one or two of the bugs. This is an easy way to show that you can be productive and useful, and will be received fairly well.
At that point, the team will probably be much more receptive to helping you find good, longer term goals and tasks on which to focus. I've had a couple of people who approached our projects more along these lines, and we've all been very happy to help them try to figure out how to fit in and mesh with the team as whole.
That's the goal - you don't want to just be a contributor in the long run, you'll want to be part of the team. That's when you start feeling ownership over the project, and when it really gets fun.
It depends on what projects you're getting into, but often a look at bug trackers will help (few devs will turn down a patch to a reported bug). If you run Linux, Gnome Love is a collection of "easy to fix" bugs that should be perfect for a beginner getting his/her feet wet. My advice would be to pick a smaller / simpler project, as the codebase is easier to get oriented to.
I haven't rode the train of a particular project, but I'd imagine you have to prove yourself to the dev team.
For instance, take a while to familiarize yourself with the code base. Look at bug reports and see if you can track down some bugs.
Once you wrap your head around things, you can submit bug fixes, or implementation of some features. Maybe write some documents to help new comers wrap their head around the code base. Basically, do anything that demonstrates that you know what you're doing.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a problem to solve that I think will take 4 days, but if I had a feature request sorted and a snapshot release then I reckon I could have it done in one. Superficially this creates a budget of 3 x my daily rate to get it the feature-request actioned.
So my questions are, have you ever paid an O/S project member to fix something for you? Did it work out OK? How did you sell the idea to your manager / colleagues and where did the money come from?
Most importantly how did you go about asking nicely? Is there an etiquette for these things? Are the project leaders likely to be receptive to the idea?
In case it matters, the software with the the missing feature is a JBoss project - the home of professional open source - and I'm able to claim expenses as I'm a contractor.
At work, we've had good luck hiring open source maintainers to enhance libraries that we use.
Here are some projects we've done in the past:
We needed to integrate Quake 2 with wxWidgets. We hired Vadim Zeitlin, a major contributor to wxWidgets. In less than 4 days, he built a wxQuake2 widget by adapting the Windows version of Quake 2.
Later on, we needed portable access to raw bitmaps. So we hired Vadim again, and worked with him to produce a new raw bitmap API. This involved a substantial bit of design work, but we really liked the resulting API, and we use it to this day.
At a later date, we hired another one of the core contributors to improve wxWidgets accessibility support. As it turned out, we ended up not using this code right away, for various technical reasons. But other people have been enhancing this code since then, and we hope to use it some day.
In other words, hiring open source maintainers is a lot like hiring any other kind of contractor. But some things are a bit different, too. Here's some advice based on our experiences:
You'll have the most luck if you want to enhance an existing project and release the changes as open source.
In general, you want to hire members of the core team. They have the best track records, they're the most productive, and they have the best chance of getting your changes merged upstream.
You want to get your changes merged upstream. If you don't, you'll be maintaining a local fork, which is a headache.
Before hiring, do some research. Who works on the features you care about? Are they somebody you'd enjoy working with? Read the mailing lists and glance at the version control history, and pick out a few people to approach.
During the design phase, there may be a bit of give-and-take. The developers are looking at the larger health of the project, and you're looking at the needs of a specific business. This has occasionally made negotiations a bit more complicated for us, but the final result has typically been a better design than we would have chosen on our own.
And most importantly, don't be shy. In any sufficiently large open source project, several members of the core team will already run consulting businesses. In smaller open source projects, you'll generally find several contributors who want to run consulting businesses.
And if you're still hesitant to approach somebody, you can always ask, "Do you know anybody who'd be interested in getting paid to work on $FEATURE?" If they're not interested, you haven't put them on the spot, and they may tell you who to ask.
On the whole, we've been impressed with the professionalism and productivity of open source maintainers, and I would recommend this route for others.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm working on a personal project and I'd love to be able to say at the end:"I've spend X hours on this project". Now one way to solve this, is to use a manual time tracker (worked from: to:). I've ran into problems with this, because I only manage to use it consistently for the first week or two. So I'd like to track development time automatically.
One idea I had was to insert a short script into the build process that that would insert a time stamp into a log file every time a build process is called. Later, I could analyze the intervals between each build and hopefully calculate a somewhat accurate picture of what's going on.
Does anyone else have an idea of how such a time tracking tool could be implemented?
Quick follow up based on the answers already provided:
Stop/start trackers aren't bad, but require a lot of discipline, something that I perhaps should be working on. But they dont work for me.
Specific app-tracking programs are great, but I'm current on Mac OS X.
My opinion is that you would greatly benefit yourself in keeping a light-weight development journal. Notes, sketches, times, dates, etc, designs. It's not an answer to your question, but it is a discipline that few developers have and one that they desperately need.
Life is busy and people must learn to track / budget their time and discipline themselves to take on good behaviors and habits.
I encourage you to fight and win this battle. Don't compromise something so easy to automation when there are greater gains if you improve your skills. You might also want to check out LifeHacker for some ideas.
A bit of a non-answer, but I hope you find it helpful.
If you use source control you can use svn (or any other) hooks on commit and checkout that log timestamps to a db, etc when you check your project out and when you check it back in.
The trick to making this work - and it is easiest on single developer projects - is to MAKE SURE you check your work in when you are done working for a period of time, and that you check it out immediately prior to doing actual work.
This might not be feasible for your project. Build process checking etc suffers from the same issues - namely that you might work for 3 hours and then build 8 hours after that.
We wrote a plug-in for our IDE (IntelliJ in our case) that keeps track of time spent per project automatically. The IDE's API lets you list for events like edits, changing windows, etc., so we log a record every time something like that happens. The reporting module looks at this raw data and determines the total time spent per project by comparing timestamps between records. If the difference is greater than 5 minutes, it assumes no work was done during this time.
It's not perfect and it's not 100% accurate but you do eliminate all the overheard of manually tracking this stuff yourself through some external tool.