PREDICTION: New Users heading this way

General
21

I’ve pretty much fully jumped ship myself (and commented over there about how they should change their approach - on the same page as user T42).

Oddly, I jumped ship just yesterday, and already like SyncThing better than BTSync - it has similar limitations but I feel I have more control over it.

Still, ST does need some UI/UX love. Running as a process in a command prompt on Windows rather than a service is not good (though there’s a work around with Non-Sucking Service Manager). Also not great that the management interface is in a browser. A few other features/tweaks that it could use - like incorporate all config in the app interface for Android. But none of this needs to be altered immediately, but certainly a piece at a time.

I’m thinking money does come into play (some kind of payment system to the ST team) if we want to see consistent dev on it. As I commented over on the BTSync, some kind of split in free vs pay version that makes sense. Or as for donations (like kickstarter) where a certain amount gets you the pro version. Just not subscription - unless it’s a small fee for the Discovery service in the “Pro” version, and you keep the ability to host-your-own Discovery server in the Free version.

I thought I read somewhere that Jakob initially didn’t intend SyncThing to be the primary focus of development, but rather the sync protocol itself, and he expected other devs to fork SyncThing or even develop other tools that utilized the protocol; SyncThing was intended as a proof-of-concept/demo.

Either way - nice work Devs, and thanks to everyone here for helping me get mine working.

1 Like
22

syncthing-android doesn’t have any problems with the license (I have no idea about iOS though).

Regarding Windows: Everyone in this project is contributing in their free time, and probably has enough to do already. If you want to see a certain feature, it’s probably best to try and implement it yourself. That’s how open source works :wink:

23

Sorry, but this has filled my glass.

So first of all, you seem to have a negative vibe, telling people that they are not trying hard enough and they don’t care. This is as far as I am concerned a hobby project, me (and I believe @calmh too) invest our own personal time working on this rather than spending time with our families. I am not getting paid to do this, neither I feel that syncthing will become a business, hence I only do this to satisfy the crowd… And then cowboys like you come along and start bossing and insulting peoples time and effort, which I think is under the assumption that this will make them work harder/invest more time. To be honest, when I read posts from people like you, I just want to say: Fuck it, why I am I even bothering with this if I have to read rants about not trying hard enough? How about you actually tone down, and help us out PROVING that YOU CARE, instead of bitching/bossing people around?

You can participate in the iOS beta that someone is running. Someone has took the effort of reimplementing the protocol to have a iOS client. For now it seems to be free, but not sure if it will stay that way in the future.

6 Likes
24

Try syncthing-gtk, it wraps everything very nicely.

25

I’m sorry, @AudriusButkevicius, I don’t want to put down the work SyncThing people are doing. I think it has been great! I think it is the most compelling option, and it is why I have been promoting it in multiple non-SyncThing forums in the last day, and it is why I have been migrating to it. I plan to switch multiple family members over to it from BT Sync. You guys are rock stars, in my and many others’ books sitting for a while at #2, but are now #1 on the charts! It is quite a feat.

It is a blow to the sync landscape to have BT Sync shoot themselves in the foot in remarkable fashion, and I am lamenting that member(s) of the SyncThing community in the past have, according to my perhaps faulty memory, expressed the attitude that

1. it is not seen as a big deal to not have an iOS client -- (correct me if I am wrong!  I am probing here) or 
2. contentment with how things are, 
3. lack of desire to a) invest time, and b) make simple choices that turn ST into a big thing that can be good for the masses because it works for them for their purposes and that's all they care about and 
4. 'we are afraid to make an iOS-friendly license because someone might take our code and profit from it, and so we would rather neither users nor developers profit from it'.

Note: 3b is a much bigger concern to me than 3a!!! I can’t fault anyone for 3a, and it doesn’t hold others back from contributing/forking. 3b does!

I just found a quote that spoke to 4 – I could try to find quotes for the others but it would be better if everyone just clarified the their vision, rethinking things if necessary, since there are potentially myriads of potential users coming here to try to determine if this is a good investment for them as users (and possibly a few contributors – I may contribute to a permissive licensed fork some day, or a windows wrapper, especially if iOS is in the mix.) This opportunity will not last very long. Now, it is totally and entirely up to you what license you choose to release your software as – you have to do whatever benefits your personal goals the most – it is just unfortunate from the perspective of me as a potential iOS user (and all the other ones) if the SyncThing community intentionally makes avoids choices that would make the availability of ubiquitous ST delayed or less likely. I question whether it is in the self-interest of the ST community, and I think they are fair questions to ask.

The big opportunity

BT Sync just triggered a HUGE mass exodus. It is a big deal! Stuff just got real! This isn’t time to tiptoe softly around people’s feelings. When times become intense, I am intentionally provocative to get a response to figure out where people stand, especially because they themselves may not have thought through where they stand. Sometimes emotions are tools to get people to think things through. This is an enormous opportunity. It is a badge of honor to be the best game in town. I don’t know why you should be offended. Maybe there should be a poll on this forum so I could give @Audriusbutkevicius and @calmh and all contributors here a 10 out of 10 for awesomeness, so you could know how appreciated you are. But it is a cold hard fact of reality that my iOS devices are not usable in the SyncThing world, and that it is harder for my grandma to install ST on Windows and nerd out on NSSM than BTSync – so what? It is a negative situation but that doesn’t mean anyone should take it personally that nobody has spent the time to improve these things to perfection.

I think it would be easier to have an iOS solution if there was a license to allow porting. (But I know the Go language makes it a technical challenge.) Honestly, I think the licensing turbulence here in the last 6 months has revealed a lack of ambition that potential new users from BT Sync like me may want to consider before placing all our hopes here, and potential contributors may want to weigh contributing to the culture here vs starting their own, with clearer ambitions and less emotional turbulence. As a user, it is a pain to have something crazy happen and reconfigure all of our sync’ed folders using new software. I prefer to minimize how many times I have to do this since it is time consuming. As a developer, it is really painful to contribute to a movement only to have it shoot itself in the foot – and at this point I don’t get warm fuzzies that I would be compatible as a developer with my personal way of seeing the world with SyncThing. (Although the BEP is a great starting point for a new project.)

On iOS and GPL:

There seems to be a preference to have neither users nor developers benefit on iOS rather than have someone potentially profit from an iOS app, and (IMHO) unwarranted fears of scamming, and that someone else couldn’t simply release a free version of ST for iOS and the market would route to the free version. Or if a hypothetical paid iOS version added value, that that wouldn’t be a good thing overall for BEP and ST in the long run.

I have been away for a couple months – it is really cool someone is working on iOS. “Someone has took the effort of reimplementing the protocol to have a iOS client.” – I can’t help but read this as “we forced someone to reimplement from scratch on iOS, because, ___” and I for the life of me can’t think of something that goes in the blank that makes sense.

I was not sure if the MIT android wrapper is licensed correctly, since it directly hosts the GPL library in a thread. Maybe that is not considered linking?? If that is GPL compatible, that is a new scenario to me! (http://stackoverflow.com/questions/3902754/mit-vs-gpl-license)

Even if the android wrapper is licensed correctly, a wrapper approach of GPL (or LGPL) on iOS and other similar app stores seems impossible due to the license chosen. If the desire is for the BEP protocol to succeed, I am not sure why there wouldn’t be a desire to have a strong, permissive reference implementation that anyone can use as a starting point on as many platforms as possible.

But again, it is entirely up to the contributors to prevent the possibilities with what people do with their Intellectual Property, if they want to preserve the possibility for themselves, or make the choice to permanently limit what can be done with the software because they see the potential abuses as greater than the potential benefit to all involved.

The trajectory of the community

Part of my provocativeness is also to try to get a feel for the sensitivities of the developers. If one guy like me can come in here and strut like a cowboy and dissuade people like you from continuing at all, I would say that being thin-skinned is a project risk, as a cold impersonal fact of reality. You guys may be rockstars, but rock bands sometimes self destruct (as with OSS projects and communities), I have sincere concerns that this developer community may be too emotional for long-term success, both in terms of stability in not making knee jerk reactions, and also in making objective decisions that are best for itself and for its community. I hope more people join the team who can bring wisdom and stability, and/or that current people can find it in themselves. I am trying to determine where I and others should be investing their time as users and potential contributors and what the risks are, and some of that includes the personalities and emotional nature of the people involved. The relationship with ind.ie blew up over pettiness, very needlessly in my not so humble opinion – what additional blow-ups are in the works? What other synergies are going to be wasted? Who is going to start a permissive license alternative to SyncThing that has an easier path to ubiquity? I think these are important questions, and I am trying to figure out what the future holds based on currently available evidence.

Less than glowing opinions may be a tough thing to hear, and I tried to sugar coat it and mix it with positive feedback, but these are my honest opinions and I think this is a time for honest discussion. BT Sync has not released any open source, so you are already miles ahead of them. It is always a special thing whenever anyone creates and gives away free software, or free open source software.

Don’t take what I say personally. I hate seeing BT Sync shoot themselves down, and for ST I hate seeing needless tragedy in in OSS partnerships destroyed, large user segments and user scenarios being (possibly) needlessly unreached, and choices being made that (maybe) slow down the growth of ST. There is a huge difference between insulting your time and effort, versus questioning (and disliking) your choices and I hope you can see that, if only for your own emotional well being.

My bottom line for sync in general: I want a good (permissive) open source sync protocol and featureful software everywhere, ASAP, as in 8 years ago – maybe SyncThing/BEP will be it, maybe an alternative OSS project that doesn’t exist yet is the most promising bet. A lot of ex-BT Sync users/potential developers are up in the air right now, so let’s figure it out!! Exciting times! There is even a lot of potential people willing to spend money for a BT Sync product (that doesn’t exist, since they went for a bizarre subscription model), and people willing to donate – as I said on the BT Sync forum, this is a large part of the recipe for a successful kickstarter campaign, even if the money goes to fund open source and not a commercial entity, or to start a business that has a open source/freemium model.

Bottom line for SyncThing What I want first and foremost for ST developers and community to think about what is truly best for them, and do it. You can never ask more of open source developers than that!! If I can help you guys figure out what’s best for you, I want to, even if it ends up not being a direction that is not compatible with me and others like me as an end-user or end-developer or contributor.

26

Hi, ex-BTSync user right here. You hit the nail on the head.

27

Here! Here!

Well put Jared.

And to the devs/contributors of ST, I’d like to re-iterate a couple points of Jareds:

  1. We think you guys (gals?) have done a very commendable job creating a sync tool that already competes with BT.

  2. Our questions/thoughts/concerns are in now way a criticism of this great work - we’re just trying to clarify what’s happening/what will be happening, and perhaps promote our own ideas/vision (or at least thought/discussion about the direction of ST).

  3. Forums aren’t the best place for these kinds of discussions- sometimes our wording/writing isn’t ideal, and may come across as criticising rather than simply analytical.

Keep up the great work, know that it’s appreciated, and that guys like me and jared would like to find some way for ST to take advantage of this sudden shift in the market - clarify the direction/vision, increase funding/monetizing opportunities, etc.

I’m no market analyst - perhaps that’s what’s needed, a Business Analyst who can speak authoritatively to how to proceed.

2 Likes
28

So I was going to reply about all the politics, but I’ll just try to summarize. Move from MIT to GPL was initiated by ind.ie, and everyone has agreed to that to help them. When ind.ie weeks later realized that GPL was no good for them (since they wanted to put something which has syncthing inside on the app store), there was a movement to switch syncthing back to MIT, but two license flips within a few weeks was I guess too much.

Now on the technical side: Given you currently cannot run Go binaries on iOS, I don’t see how Syncthing not being GPL helps iOS. The protocol implementation is already MIT, and that’s pretty much the core of what syncthing is, the rest is just some glue to make it all work. If a day comes where you can compile .so’s with go and link against them, you will already have more than half of the implementation.

Even if the glue is GPL, you cannot enforce GPL on an algorithm, and given you cannot run Go on iOS, I don’t see what you are loosing out on, as you can still look at how the glue is implemented, and port it.

The reason someone has re-implemented things in iOS (if I am not mistaken) not because of the license, but because you couldn’t do anything with the code even if it was public domain.

I am not saying GPL is the right answer, nor do I have a strong preference. I do feel for the developers, and I do want people to build awesome stuff on top of syncthing, or more people to join making syncthing.

I do understand that your approach was to make people wake up, but you have to understand that we are under limited resources. I would love to spend more time on syncthing, perhaps even work on syncthing full time, but sadly my local supermarket does not accept github commit hashes as a currency. But to be honest, I’d rather you come and help us out, rather than trying to teach us or challenge us.

3 Likes
29

Yeah, this is part of why I don’t understand why there is a desire to stick with a decision (GPL) that even the initiator (ind.ie) realized was a bad idea. I have been trying to come to peace with the rationale / rational rationalization for staying GPL but I am struggling.

It looks like there is at least some effort to get Go on iOS.

I think the value of the glue, in the form of a working application, should not be underestimated. Instead of saying “here’s a fully functional app that many people have already tested, and use, and added some nice features to”, you are saying “here is a protocol, go make a fully functional app.” I think the barrier to getting started is order(s) of magnitude higher, especially as more nice features get added to ST.

You may have a point, and I may overestimate the value of ST, but perception matters, and if the flagship development of BEP is under a restrictive license then the perception is hurt in the minds of people like me.

I think you underestimate the power of copyright law, and the fear it invokes in people that they may building something that is in violation.

Check out the Mono contribution rules. Rule #1: “If you have looked at Microsoft’s proprietary implementation of .NET or their shared source code (which is also proprietary), you will not be able to contribute to Mono.” If you even LOOK at the source which is licensed under a restrictive incompatible license, you are in danger of accidentally bringing over code that is too similar! I agree, algorithms aren’t covered, but copyright does cover implementation. [Note: Microsoft has seen the light and embraced permissive open source in the core of .NET, and used the permissive Apache 2.0 license, so the rule doesn’t apply to Mono anymore, but the principle for copyright law still does.]

Would the ST authors be impressed if someone took a tool to automatically port ST from Go into C++, and re-licensed into the public domain? (So they could turn around and use it and extend it in proprietary commercial projects and become billionaires.) I think they would be upset, and IANAL but I think they would have grounds to sue. And then someone could take the public domain C++ code, run it through a tool to get Go code that might very closely resemble the original source. Bam. Instant copyright nullification. But that’s not how the world works. Copyright law is stronger than that.

Whether an automated tool does this or a human being does (intentionally or accidentally), my understanding is this does not make much difference in a court of law. I for one would be afraid to look at the GPL glue, out of fear I would accidentally infringe, or be tempted to push the envelope.

If this were true (and I don’t think it is), why have the restrictions of the GPL at all in the first place?

I for one would google “Go trans-compilation and conversion tools” to see if there was an easy way to port ST to iOS using another iOS language like c, objective-c, etc., or something that runs on iOS and everywhere else like C#. Or I would look at how many lines of code there were and see if it was a big task to port it by hand to my cross-platform language of choice. But because the license is GPL, the end result would have to be GPL, which makes it a non-starter for the App Store, plus many other potential uses I can envision for the software.

On a tangent: how many apps use Apple’s iCloud to sync data? A lot. Why couldn’t SyncThing be used to help implement this on a cross-platform basis for apps? I think that would be a cool use case. I am interested in this possibility. But the GPL makes it a non-starter. It is nice the protocol is open source but when people have limited resources, it is nice to not have to start from nothing (or just a protocol) when building new functionality. Every little bit helps…so why not help? There may be a good reason why the ST community would choose to be less helpful, but I just want to make sure it really exists.

I hope you guys maximize what you accomplish with those limited resources! We are at a point in tech history where this could snowball into something big if you play your cards right. The potential to attract more resources is here, right now.

[quote="AudriusButkevicius, post:28, topic:1937] I would love to spend more time on syncthing, perhaps even work on syncthing full time, but sadly my local supermarket does not accept github commit hashes as a currency.[/quote]

Someone should start a kickstarter, or a few, so ST devs or other devs can quit their jobs for a while and add some features. I’d consider it if I didn’t have other things I’m working on. I’m not loaded but I would chip in a little. Kickstarter campaigns can be a lot of work, so check out Backer, a crowdfund platform for software features, or Tilt.

Thanks for the invitation. I would appreciate the chance to be a part of a solution and it would be an honor to help on this great project. However, as you can guess by now, I can’t see myself ever contributing any significant time to a restrictive GPL sync project because I myself wouldn’t be able to make use of my own efforts on my iOS devices or as add-in functionality to my software.

30

I’m one of those BTS refugees. Imagine my happiness when I found you and Syncthing!

While I’m on linux and it just works, I’d try to help with the UX in general (I’m on that since 1994) and testing also the android version.

Anyway, thank you very much for the great spirit of ST. :slight_smile: Best…

– e

2 Likes
31

As I mentioned earlier, I’m a BTS refugee too. First of I’ll, I’m really happy you folks have spent so much time building SyncThing. Thank you.

As an OS X and Windows user, I like what appears to be some upcoming features/additions. I do wish the inotify module was part of the core SyncThing, but maybe that’s on the way. It does have some issues with OS X and until that gets a little better I’m stuck syncing some smaller sets and living without it. But, those small sets have so far have worked perfectly. I can’t wait to see more.

But, the point is that I believe it will get there. I can’t wait to see more.

32

Please be aware that it is absolutely not a surprise to welcome a lot of former BTSync users here (I am one of them). I think everyone, including the SyncThing developers, were expecting that as soon as the version 1.4 was released and never really fixed. It was just a matter of time before Bittorrent completely shoots itself in the foot by releasing a free version with limited features.

From what I have seen, SyncThing is maintained by 2-3 developers who are working on the software on their free time. They don’t seem to do it for money, but because they like it, just like any hobby. Why would they invest time and energy to gather funds or include functionalities which will make the maintenance much more complicated? The goal here is not to be a challenger to BTSync, but an open source alternative. There is a huge difference.

Think about this comparison: imagine that your hobby is tuning/repairing your own car. You spend evenings and weekends doing that, alongside with a 9 to 5 job. One day, the professional car mechanic at the corner of the street closes down, leaving hundreds of customers helpless. You have two choices: take profit of this opportunity to take over the business in the area, or continue your hobby as nothing happened, and maybe give a hand to some people begging for help. SyncThing team seemed to choose the second option.

Keep in mind that this software is to be considered like a hobby, without any time or financial constraints (at least, that is my point of view). Don’t expect to see the developers start working on features upon requests. They will work on it if they are interested to do so, even though any code contribution is welcome. The advantage is that the software will tend to keep a constant quality; the drawback is that some requested features will never be developed.

To come back on your “you would be pissed off if someone steals your idea and make millions”, well, think about it with another perspective. Would you be pissed off if you refused to take over the professional car mechanic business and someone else did it and made millions? Would you be mad if someone starts to make money while you are only spending time on your hobby? If so, you are stupid.

2 Likes
33

@AudriusButkevicius and @calmh I know you said that you never wanted to accept any money to move the project forward but with the sudden influx of users (and I imagine you have a big swarm if you check your web statistics), wouldn’t you consider a Magic Backlog just like Robomongo (an open source Mongo client)?

I’m sure it would work well if it suits you.

2 Likes
34

SyncThing team seemed to choose the second option.

Yeah, I am coming to this realization. It took me several months to figure this out. Being naive, I thought there might be devs here who would think it would be cool to grow to become the dominant sync solution for tens of millions of people over the next decade. But since I find that hard to believe that people may not be excited about that, I am still trying to confirm it from the devs themselves.
If it is true, I hope the influx of users (many of whom may be programmers) from BTSync figure this out right away so that they have fair expectations about this being only a spare time deal, and can decide now en masse whether they want to wait for a few hobbyists to slowly make things better (probably being eclipsed at some point by somebody or something), or try to contribute or gather resources for a more concerted effort.

Would you be mad if someone starts to make money while you are only spending time on your hobby? If so, you are stupid.

Wait, are you calling ST devs stupid? (For guarding their hobby inventions (via GPL) from being used to solve the epidemic of broken cars, because some mechanics might set up a shop and make a buck from helping people.) If not, I am not sure I understand where you are going with this or if you are directing it at me, and if so, while I may not comprehend that mindset, I think that may be a little to blunt to use insults like that for people who are actually at least fixing a few peoples’ cars and releasing their blueprints (of the protocol) in a permissive way for anyone to try to replicate with some extra effort.

35

+1 for backlog management idea from @Rewt0r - or some derivation of the concept.

Let’s assume that the BTSync user base is 100 times larger than what exists now at Syncthing (wild-assed guess). And, let’s assume that 10% of BTSync’s users migrate over here due to their dissatisfaction with recent developments over there.

Whoa! That represents a 10X increase in the user base over here. And these new users come with a different set of experiences and expectations about what a sync product should look like.

Given the limited resources here, a potential 10-fold increase in forum traffic, new issues, and enhancement requests will be a huge challenge to manage.

This might be a good time to consider a systematic approach to prioritizing the development list. At the same time, we have to thoughtfully consider that this is a hobby project, and we don’t want folks like @calmh and @AudriusButkevicius to feel like they are enslaved to community-set priorities and deadlines.

EDIT: Theoretically, this could increase the number of willing developers 10-fold - which is a good thing. Or a bad thing if there is no methodical process to prioritize and organize activities.

1 Like
36

I found this roadmap, but I’m not sure whose roadmap this is. A roadmap may help out new users/contributors get a picture of where things are headed.

37

Hey jared, I’m not clear on the GPL implications (re:iOS) and “MIT to GPL” (what does “MIT” mean relative to GPL?). I understand that GO wasn’t developed for iOS, but it sounds like there are some wrapper options. I’m familiar with the basics of GPL, but I realize there’s more than just GPL (nuances of how code can be GPL).

Would you mind starting a new thread from this post just to clarify some of the implications re:ST (I realize that’s asking a bit) or could you point me to threads that help clarify?

Thanks

38

This is my concern - the current devs are doing this as a hobby (which I have absolutely no problem with).

If this is the case, what can I do to help move ST (or a derivative/fork) into a fully-staffed dev project?

In my professional life, I tend to work as a project engineer/business analyst/systems integrator. I “shepherd” new systems into enterprise environments. As a Business Analyst I’m responsible for working with the business unit (think end-user) to develop business requirements and translate them into systems and technical requirements, and then developing the system design and implementation plan. So I have moderate technical skills (having supported windows/networks for 20+ years), but not dev-level tech skills.

So of course my brain is thinking high-level “what is the end goal, where do “we” want ST to go?” And who is the “we” in that question?

Seems like that’s the discussion that needs to take place, with players who really want to get involved to take some of the pressure of the current ST devs, and let them be SME’s/leaders.

1 Like
39

Right, I’ve just spent the last hour and a half creating an x86/x64 installer for Windows users but before I distribute it I just need a response from @Alex that I can distribute his syncthing-tray application.

Sit tight :smile:

1 Like
40

Awesome! There is hope for my grandma :grin: